BOSTON -- There is no silver bullet that will single-handedly transform an application's performance from a slow jog to an all-out sprint. Improving performance requires a variety of programming best practices. Many were on display at the recent VSLive conference in Boston.
In "Make it Go Faster," Brian Randell, senior consultant at MCW Technologies, provided hints on several fronts, from timing code to using arrays to minimizing exceptions.
Late binding is one thing to avoid, Randell said, because it requires additional work at runtime. Both calls and operators on an object will cause late binding, he said.
Other practices to avoid are multi-dimensional arrays and slow conversions. In the former case, Randell said arrays of arrays work better. In the latter case, he noted that filling a collection with integers will make that collection a boxed object; to use any of those integers, that object has to be unboxed and then reboxed when it is time to return the integer to the collection.
Overuse of exceptions will also hurt performance, Randell said, adding that "Try…Catch" provides better code flow.
Another costly overuse is the call across a runtime boundary -- whether that call is a declarative statement, a COM object, and AppDomain or a Web service. Try to reduce round trips as much as possible, Randell said.
Randall's biggest piece of advice: "Don't try to outthink your compiler."
Also offering a series of performance hints was Jackie Goldstein, principal of Renaissance Computer Systems. Goldstein used a quiz format to present 13 code samples that exemplified bugs, performance issues or just plain bad code.
Goldstein, too, cautioned against using exceptions liberally. For starters, he said, the CLR is optimized for non-exceptions, so exceptions should not be thrown for anything that will occur more often than not. Moreover, he added, exceptions should not be required in a common path, should not be wrapped in a larger exception and should not be so specific that related exceptions are missed.
Other practices worth avoiding are assuming that an enumerator will have a set value and will not change and using the constructs lock(me) or (lock(typeof<something>, Goldstein said. In the latter case, the better option is to lock onto a preferred method.
Finally, Goldstein said developers had no reason to call the Garbage Collector method, since it is regularly tracking how memory is used and released. "Let it do its thing, since 99% of the time it knows better than we do," he said.