Article

VSLive: Getting the most out of smart client apps

Brian Eastwood
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.

Don't try to outthink your compiler.
Brian Randell
senior consultantMCW Technologies

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.

More on application performance
Tuning .NET apps(TheServerSide.NET)
Part 1 | Part 2

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.

  • Return to "Special Report from VSLive! Boston"
  • There are Comments. Add yours.

     
    TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

    REGISTER or login:

    Forgot Password?
    By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
    Sort by: OldestNewest

    Forgot Password?

    No problem! Submit your e-mail address below. We'll send you an email containing your password.

    Your password has been sent to: