VSLive: Getting the most out of smart client apps

Performance is everything, and though there is no silver bullet for making an application go faster, there are many best practices for improving performance.

This Content Component encountered an error

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"
  • Dig deeper on Smart client application development best practices

    0 comments

    Oldest 

    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:

    -ADS BY GOOGLE

    SearchCloudComputing

    SearchSoftwareQuality

    SearchSOA

    TheServerSide

    SearchCloudApplications

    Close