tags:

views:

682

answers:

6

I'm not sure if the question title is the best one but it was the best one I could come up with...

I have this .NET (C#) applications which starts up with Windows and remains opened until the computer is turned off. The app stays on the tray and I open it by clicking the tray icon and close it the same way.

The app is not slow at first, it works normally, no problems there. But after long periods of inactivity of itself, it gets very slow when showing it again for the first time in a long period. Know what I mean.

For instance, I could not use/open (click the tray icon) for a few days and between those days I opened and closed and used lots of other apps, heavy apps too and I probably hibernated and resumed the computer a few times and when I needed to open my app again, it was slow. After a few minutes of using it, it goes back to normal and works fine.

I believe this has something to with memory management and the system probably frees up most of my app's memory so other programs can use it more efficiently. And maybe .NET memory management as something to do with it...

Whatever the reason, is there anything I can do to optimize my app regarding that issue?

+5  A: 

You can use the .NET memory profiler to get a good idea of what your application is doing with memory over time. You can check if anything is building up where you don't expect it to (collections, lists, etc.) and causing your memory footprint to grow.

JP Alioto
I'll give it a go...
Nazgulled
+2  A: 

Have you tried double-clicking in Process Explorer on your running app and observe it for leaks? Is it CPU utilization, UI leak, memory leak, recurrent I/O?

GregC
Where can I find if something is leaking? I couldn't find that information anywhere in process explorer...
Nazgulled
It takes observing it over a period of time. If object aor memory counters consistently grow, you have a leak.
GregC
+8  A: 

This is almost certainly due to memory being paged out to disk.

When you cease using your application and other applications or tasks start exerting memory pressure, pages of memory from your app can be written out to disk. When you try to use your application again, all this data must then be read in causing the stalls that you see.

Unfortunately, there is no good solution - if you run as administrator or have the SeLockMemoryPrivilege, you can lock parts of your application into physical memory. You can try "touching" pages periodically to keep them in physical memory. Unfortunately, both these options will cause your application to interact badly with other applications on the system - your memory is getting paged out because the physical memory is needed for something else. You can attempt to lower your overall memory footprint, but you will still run into this issue in some cases. There are options for tweaking your working set size, but the OS is free to ignore those, and will in many cases.

Michael
I am only hoping you don't use these techniques in your apps. "Play well with others" is my motto.
GregC
No ... there are a few apps where this sort of control is necessary. SQL Server for instance, maybe some embedded systems where there have to be responsiveness guarantees and so on. For normal client apps this stuff is almost never a good idea.
Michael
A: 

Hi, I reckon that this behavior is normal in Windows. Windows will serve the application that is need it most, ie, the application that is currently in used. Thus, if an application is minimized or not active for pro-long duration, like the case specified above, it will be the best candidate for Windows to page the application memory and make available memory to active application. Windows will restore the application memory when it get active from paging memory (hard disk), thus this explain why it is slow.

This might be not the best answer, but if I were you, I will experiment by increasing the base priority of the application. This can be done by using Thread object in .NET framework.

Thanks.

Nordin
I'm not sure increasing the priority is the best course of action - it sounds like a background app so having it take precedence over other foreground apps seems like a bad idea to me. It all depends on how important the app is I guess.
Jamie Penney
A: 

This isn't a root cause answer or solution, but if Michael is right and there's nothing you can really do about it, then you might just want to consider visually informing the user that your application is active with a progress bar or nifty progress circle.

It won't speed up your program, but it may ease the minds of your users just a little bit.

Aaron Daniels
+1  A: 

If the issue is indeed that the program is being paged out due to an extended period of inactivity, have you tried setting a "keep-alive" timer, that fires every few minutes, that basically keeps the application in a state where the paging system doesn't ever see it as idle?

Tom Moseley
What would that timer do when it fires? Nothing? Or something special?
Nazgulled
I thinnk that that might require a little experimentation. If having it performa a no-op keeps the application from paging as inactive, that should be sufficient.
Tom Moseley
I'm not sure what you mean by "perform a no-op"...
Nazgulled
I mean that the timer my fire and not actually do anything other than fool the application into thinking it's active. iow, an empty method call.
Tom Moseley
I see, I'll have to try that... The problem is that I don't have any good way to test this...
Nazgulled
This solution didn't work that well...
Nazgulled