File Open Performance -- Beware of 'Extensions'

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