Share via

File Open Performance -- Beware of 'Extensions'

  • Article

Here is a little interchange I had a few days ago; "Nick From Chicago" graciously allowed me to share it nearly verbatim.  I'd like to claim that I was psychic in diagnosing this but as you can see in the thread it isn't the first time I've run into this problem.

Read on :)

 

From: Nick From Chicago
To: Rico Mariani
Subject: VB.NET App Eating RAM for Breakfast

Mike Stall accused you of being a "Performance super-guru" - so I thought you might be able to answer this one.

I usually run my (VB.NET 2005 SP1 WinXP 32-bit) app through visual studio debugger. The hosting process takes up a grand total of 22k RAM.

So far, so good.

But when I run the NGEN'ed release version, it asks for 120 MB RAM just for hello...

And when I hit this line in the code:

If TheOpenFileDialog.ShowDialog() <> Windows.Forms.DialogResult.OK Then

My RAM usage skyrockets to 170MB RAM, as soon as the Open File Dialog box appears.

I tried to profile it...and by the time the CLR profiler loads the app, I'm up to over 1GB virtual memory. The profiler claims the app is using only a few KB or so of memory. The highest number I got was about 16MB for the Kernel (unmanaged code).

Am I missing something? I somehow don't think my app should need this much RAM.

Nick

From: Rico Mariani
To: Nick From Chicago
Subject: VB.NET App Eating RAM for Breakfast

When running the CLR profiler you might get better results if you set it to record only allocations and not all call stacks there is a little option for that.

I suspect that the bulk of the memory usage is coming from the file open dialog itself though which is not managed. That dialog is actually a "mini" version of the explorer and it can include explorer extensions and so forth right into your process. Sometimes when memory skyrockets like that the culprit is some kind of explorer extension that you may not even know you have.

When my friends have bizarre memory usages on their systems I generally start by uninstalling shell extensions and other things like that. Some of them are not friendly at all.

The technique on this posting:

https://blogs.msdn.com/ricom/archive/2004/12/10/279612.aspx

Could be helpful in accounting for all your memory usage no matter where it came from.

Bests,

-Rico

From: Nick From Chicago
To: Rico Mariani
Subject: VB.NET App Eating RAM for Breakfast

Wow! I spent about 2 hours un-installing two years worth of accumulated junk; what do you know, I'm down to <20K RAM usage for my app!

Thanks for all of your great advice, I hope never to become one of the people writing apps that cause these kinds of problems!

All the best,

Nick

Comments

  • Anonymous
    November 03, 2007
    PingBack from http://msdnrss.thecoderblogs.com/2007/11/04/file-open-performance-beware-of-extensions/

  • Anonymous
    November 04, 2007
    I've seen this before too, it's almost always extensions. You can also get the appearance that your application is using more RAM that it really is when using the OpenFileDialog without any extensions.  Because it is unmanaged, it doesn't have the wonderful garbage collector to defragment your allocated memory.  If you switch to preview mode when the OpenFileDialog is opened it will use quite a bit of memory when you start viewing directories with pictures in them.  After you close OpenFileDialog your memory usage may be higher than before because of fragmented memory and of course no amount of GC.Collect calls will affect it.

  • Anonymous
    November 04, 2007
    How can we make sure that those resources are released when not in use?

  • Anonymous
    November 04, 2007
    So why was it using 120Mb before displaying the open file dialog (supposedly the culprit)? Cheers Matt

  • Anonymous
    November 07, 2007
    No idea :)

  • Anonymous
    November 11, 2007
    Did some blog reading today, and found out several assumptions I had which were wrong: Assumption : &quot;