3

We have an application with very heavy UI. Recently our clients started complaining to application startup performance. (Previously our controls/forms were initialized while a some kind of the splash screen with a message 'starting' was shown).

I've made a research and found that the control's InitializeComponent() (which is generated by VS designer) method call can take up to ~0.4-0.5s for complex controls. And there are a lot of such controls, so I'm getting ~10-15 seconds of application startup time as the result. There are nothing that could be really heavy there, only controls initialization (for example, different toolstrips, toolstripbuttons, menustrips initialization, setup of different texts etc).

Is there a way to improve performance of controls initialization in this case? Maybe some kind of caching or smth like that (so our application will start up slowly only during the first load)?

P.S. We're using .NET 2.0

Thanks in advance.

Andrey
  • 5,906
  • 4
  • 24
  • 30
  • Complex winform controls are really slow. Either initialize them when needed(by placing them in seperate panels that are loaded on demand) or initialize them in the 'shown' event so the user sees 'something'. – CodingBarfield Feb 24 '11 at 12:31
  • We've had similar issues as well. I'd recommend starting the app with a 'shell' and branch off different functionality into different modules/usercontrols/child forms. That way, if a user doesn't require a module, he won't be hit with the penalty at startup. – Jake Berger Aug 02 '11 at 14:55

2 Answers2

1

You indicate that you've performed at least some rudimentary analysis of your app's start-up time, but have you thoroughly profiled your app using Visual Studio's profiler, ANTS or similar?

Thoroughly profiling of your app will give you the most accurate break-down of where your app spends its time. Anything less and you're just guessing.

You might also consider NGEN'ing portions of your app and re-profiling your app's start-up times to determine whether the NGENning of your code actually delivered a performance boost.

However, if you've built something that's very complex, you may simply be asking too much of your users' machines. This is why it's VITAL to measure performance of your code on tin that's as similar as possible to your end-users' hardware and environment.

Another thing to consider is that WinForms doesn't really take advantage of modern-day hardware accelerated graphics. You may find that porting to WPF gives you just the boost you need, but be sure to prototype and profile carefully before committing significant resources to this path.

HTH.

Rich Turner
  • 10,800
  • 1
  • 51
  • 68
0

  • Load data asynchronous

  • Buy faster pc's

  • Use WPF (.net 3.5)

Ralf de Kleine
  • 11,464
  • 5
  • 45
  • 87
  • 1
    For your second bullet, you mean increase minimum requirements to run app. – tzup Feb 24 '11 at 07:54
  • 1
    We do load data asynchronously, the problem is in UI initializing, we can't do it in, for example, in other threads. Is is also not an option to tell client that they need to upgrade their PC to use our product, or force them installing .net 3.5.. – Andrey Feb 24 '11 at 07:59
  • @rdkleine: WPF is slow AFAIK. See http://stackoverflow.com/questions/202079/wpf-versus-winforms – Numan Feb 24 '11 at 08:09
  • 1
    @System.Exception: Huh? Where are you getting that? How can you make the claim that "WPF is slow". Slow how? Slow in what context? WPF uses DirectX and, by extension, hardware acceleration (when available) and (in my experience) is much faster than WinForms in terms of UI element creation/maniulation and rendering. Have any facts to back that claim up? – Ed S. Feb 24 '11 at 08:20
  • @System.Exception I don't agree. – Ralf de Kleine Feb 24 '11 at 08:20
  • That said, if hardware (GPU) acceleration is not available, rendering does take quite a hit. It does come down to hardware in this case, but I don't think such a blanket statement is warranted. – Ed S. Feb 24 '11 at 08:22
  • @Andrey It depends on the customer and the application I think. .net 3.5 is standard in W7 if I'm not mistaking. – Ralf de Kleine Feb 24 '11 at 08:23
  • To add some perspective; I recently re-implemented a WinForms UI in WPF. Rendering and operations like creating/dragging multiple UI elements was *much* faster than it was in WinForms. Of course, I am not running an integrated graphics GPU/CPU. – Ed S. Feb 24 '11 at 08:24
  • @rdkeline: I posted the link based on which I made the claim, have you seen through? Another practical example is VS2010, which is built using WPF and it is dead slow when compared to VS2008 UI wise! – Numan Feb 24 '11 at 08:24
  • Re-implementing in WPF is not an option because it requires a significant investing of resources in our case... – Andrey Feb 24 '11 at 08:29
  • @rdkleine: Also see this, a question posed by me and the last answer to this http://stackoverflow.com/questions/2997301/net-4-0-slower-than-earlier-versions-is-that-true/2997403#2997403 – Numan Feb 24 '11 at 08:32
  • Interesting that you link to an answer that is anecdotal at best. I personally switched from VS2005 to VS2010 recently and haven't noticed much difference. You are also comparing an editor written in C++ to an editor written in C#/WPF, so I don't see how that applies to .NET WinForms v WPF, (given WinForms is the underlying framework.) Your comments come off as little more than hearsay/gossip; how about posting some numbers? Why don't you lay it out for us in a way that can't be disputed? Until you have some real data I can't take anything you say here seriously. – Ed S. Feb 24 '11 at 08:47