Developing Optimized Custom SDK Applications


Writing custom SDK applications is a fairly easy task. Optimizing them takes a little thought.

Imagine you have somehow got a ChangeRequest in hand. Perhaps you looked it up by ID or found it in a ViewMemberCollection. Now you decide to query its synopsis property, and display that in a UI.
You can call ChangeRequest.getSynospis(). If the synopsis property value is not in StarTeam SDK memory,
the SDK issues a call to the Server, i.e. a network round trip, and fetches not just the synopsis property value, but all other property values for that CR. That's not a bad thing. It's a fairly standard lazy loading strategy.
But imagine now that you have a 1000 CRs and you want the synopsis property value for all 1000.
As you iterate over each one, and ask it for the synopsis, if that property has not been loaded in SDK memory, that's 1000 server calls. Now that's a really bad thing!
In this case, the correct solution is to pre-fetch the synopsis property value for all 1000 CRs before iterating over the collection. There are 2 advantages to pre-fetching. You populate all 1000 CRs in 1 server call.
You only pre-fetch the property values you are interested in, thereby keeping your SDK memory footprint under control. Use ViewMemberCollection.getCache().populate(PropertyCollection) to pre-fetch properties.

Note that applications un-concerned about the quantity of client memory required (e.g. 64 bit applications) can choose to use ViewMemberCollection.getCache().populate() and fetch allthe  property values of an artifact list. This approach has the inherent side effect of querying and retrieving all the data associated with an artifact type, across all selected instances into client memory. However, careful memory management, such as closing views, or discarding all artifact memory caches, in conjunction with pre-populating and fetching everything up front, is a perfectly reasonable approach to proper memory management and low bandwidth client server traffic.

To address the general problem of issuing the fewest possible server commands - implement a Server Command Listener and monitor the network traffic - i.e. all commands issued by your code to the StarTeam server.

See NetMonitor.{add/remove}ServerCommandListener. There are plenty of examples of it in the test suite available through this forum.
Turn it ON in debug, turn it OFF in production.
You'll quickly see when you are issuing more server commands than you should be.
For most anything you can do 1 command at a time, there are probably ways to do the same thing in bulk.
That's how you optimize your code, reduce network traffic, minimize load on the server, & develop responsive applications.
Watch for 'isPropertyFetchTriggered' on ServerCommandEvent. If you see 100's of shortlived commands in sequence (which return TRUE for 'isPropertyFetchTriggered'), that's a bad sign.
This means you are not pre-fetching properties/bulk loading objects (e.g. Folders, Files, ChangeRequests etc) but rather, accessing properties at runtime, each access thereby issuing a new server call.
Look for examples of PropertyFetchTriggered & PropertyNameBeingFetched in the test suite.

When developing custom StarTeam SDK applications, NetMonitor & ServerCommandListener are your very best friends!


How To-Best Practice
Comment List
Related Discussions