I have .Net 3.5 SP1 with developement done in WPF.
Whenver I run my WPF application I see a process named "PresentationFontCache" appears in my Process List (on Task Manager). The process, though appears harmless, actually resides in the memory even after the WPF application is closed. What is this process actually? What does it do?
So when I try to check the memory usage (by executing and closing the application numerous times) the process gives a feel that some memory is still in use. also I have observed that this process can turn nastily resource hungry (30% CPU usage and/or 100 MB memory usage under certain conditions!!!).
I located the windows service, named "Windows Presentation Foundation Font Cache 3.0.0.0", which is probably responsible for generating this process. This service claims that it optimizes performance of WPF applications by caching commonly used font data. WPF applications will start this service if it is not already running. It can be disabled, though doing so will degrade the performance of WPF applications..
But then why doesnt the windows service itself close the process after the WPF application is closed.
Or is it that this services actually caches the font information used for any WPF apps collectively so that next time any of the similar apps, when rerun, will use the cache without regenrating the fonts for the application? If so isnt that a type of data which cannot be garbage collected? Isnt that a probable cause leading to memory leak?
Please elight me.
Thx
Vinit.
This service is designed to improve the performance of WPF applications and increase the amount of shared resources between WPF programs (or different instances of the same program). The source is available for it as part of the Reference Source Code Center, and some more information on WPF application performance in general can be found here.
There are isolated instances of where this service causes a problem, but for what it's doing I don't think that occasional CPU spikes and 100mb memory usage are problematic.
You can safely disable the service if you believe it is taking up too many resources, but you're better off profiling / measuring what effect that has on your application.
Related
I'm about to deploy my new WPF application and I've just noticed in the Task Manager that it was consuming a lot of memory. So I downloaded a trial of RedGate Antz to try and find out what was causing this issue and I was shocked to see about 90 MB of unmanaged memory usage. Because Antz does not support unmamaged memory I then tried to use Windbg which did not point to a high usage itself. This leads me to believe it must be one of the DLLs I'm loading. I'm using the DevExpress controls in my application.
An interesting feature is when I minimize my application the memory drops right down from say 110 MB to about 6-10 MB.
Should I be concerned / worried?
This is my first WPF application and I'm not totally sure what to expect in terms of memory usage. Does the fact when minimized this memory is regained/given up a sign that everything is ok?
Any thoughts or ideas on what could be causing this would be most helpful.
I've had good luck with SciTech's .Net Memory Profiler (memprofiler.com) if you want to know specifically what's causing it.
With the nature of the .Net runtime, if you're running on a machine that has plenty of memory available then it will generally try to use it. If you start seeing performance problems related to it then you should worry, and generally it's good to be aware of what is using resources regardless. A probable reason for the drop in memory is one of the DLLs may hook to your main Window's events and invoke a garbage collection on minimize.
If you're concerned about the perception of high memory usage there are tricks you can play to massage the numbers that show up in TaskManager (like p/invoking SetProcessWorkingSetSize), but that doesn't seem to be really what you're asking about.
I have developed an application in WPF with C#. The application includes a third party dll for displaying the camera in a particular window.
Normally the application takes the memory 90 MB - 135 MB without camera object (Unmanaged object). i.e I removed all the code reagrding the camera object in the design and code page (xaml and xaml.cs). The memory increasing and stops at one max value.
If I use the camera object in the application, the memory is increasing gradually. When I open the camera window every time, the memory will be increased gradually like 135 MB 141 MB, 143 MB....
I have used GC.Collect and the Using statement for all necessary place to clear the managed memory. I am not able to reduce or stop the memory increasing.
How to solve this issue?
Any suggestions will appreciate
Thanks in advance.
Using GC.Collect typically doesn't reduce your memory footprint. Stop calling that and you may see some improvement.
On a more general note, you shouldn't worry so much about the perceived footprint of your .NET application (especially if you're monitoring it through Task Manager!). The .NET runtime will release memory when it needs to - for example when under pressure, or when idle - and so the value you're seeing isn't necessarily indication that it's using more memory - it's just reserved memory for the time being.
One small test that can demonstrate this: what happens when you minimise your .NET app? Very often you'll see memory use in Task Manager drop dramatically, and it won't come back up immediately when you redisplay the window.
It seems you have answered your own question:
If I use the camera object in the application, the memory is
increasing gradually. When I open the camera window every time, the
memory will be increased gradually like 135 MB 141 MB, 143 MB....
I have used GC.Collect and the Using statement for all necessary place
to clear the managed memory. I am not able to reduce or stop the
memory increasing.
As stated above, GC.Collect only perform garbage collecting on managed objects, NOT unmanaged object. I assume the memory leaks comes from the camera object you used, not from the managed code. Then why bother you blame GC.Collect for high memory rises?
This is why I assumed the blame on the camera object:
Normally the application takes the memory 90 MB - 135 MB without
camera object (Unmanaged object). i.e I removed all the code reagrding
the camera object in the design and code page (xaml and xaml.cs). The
memory increasing and stops at one max value.
If I use the camera object in the application, the memory is
increasing gradually. When I open the camera window every time, the
memory will be increased gradually like 135 MB 141 MB, 143 MB....
Then you should investigate the camera control you used. It's obvious, the culprit is the camera control.
Does the unmanaged camera component have a C# wrapper? If so does it implement IDisposable? Ensuring you dispose the camera object (if wrapped) will call its destructors in unmanaged code
Is the unmanaged code connected to your C# code via DLL import? If so ensure you are calling all "Close()" type methods to free memory in C#. I would advocate wrapping the camera component in your own .NET class implementing IDisposable in order to neatly package this up
Are you subscribing to any .NET events and not unsubscribing? Such as Camera.ImageReceived += new EventHandler...
Leaving subscriptions to .NET events open can cause a subtle memory leak as the GC cannot collect an object while there is a reference to it (via event subscription)
Finally, a crude test to check for memory leak would be to leave your app running overnight with multiple create / delete camera window operations. See if you get an OutOfMemoryException the next day. As previous posters mentioned Task Manager is not going to report accurately the memory usage of a .NET app, however the acid test is does the GC eventually free the memory or does it keep growing indefinitely?
Does anyone have some suggestions for issolating resource and/or memory leaks in a WPF application?
I have verified that there does appears to be some significant leaks in our application through the monitoring of heap sizes in Task Manager while using the application. I did download the evaluation of the Memory Profiler tool, played with it for an hour or so and moved on. Now my evaluation period has expired. While using it many issues were reported, but I had not invested the time to wade through all of the verbose report.
What is the best tool for this? Should I invest the time and money on Memory Profiler or go with something else. I used to use BoundsChecker in C++ and it was great, slowed down the application a lot but pinpointed right where you had an issue.
I would like a tool to identify the source of our leaks.
Any .net memory profiling tool would do. For WPF specific memory profiling we used http://msdn.microsoft.com/en-us/library/aa969767.aspx.
But we could also do better memory profiling of our WPF application using WinDbg .... even SOS helps. You just need to have a way to understand its commands.
So, I'm building a WPF app and did a test deployment today, and found that it performed pretty poorly. I was surprised, as we are really not doing much in the way of visual effects or animations.
I deployed on two machines: the fastest and the slowest that will need to run the application (the slowest PC has an Intel Celeron 1.80GHz with 2GB RAM). The application ran pretty well on the faster machine, but was choppy on the slower machine. And when I say "choppy", I mean the cursor jumped even just passing it over any open window of the app that had focus.
I opened the Task Manager Performance window, and could see that the CPU usage jumped whenever the app had focus and the cursor was moving over it. If I gave focus to another (e.g. Excel), the CPU usage went back down after a second. This happened on both machines, but the choppiness was only noticeable on the slower machine. I had very limited time to tinker on the deployment machines, so didn't do a lot of detailed testing.
The app runs fine on my development machine, but I also see the CPU spiking up to 10% there, just running the cursor over the window.
I downloaded the WPF performance tool from MS and have been tinkering with it (on my dev machine). The docs say this about the "Frame Rate" metric in the Perforator tool:
For applications without animation,
this value should be near 0.
The app is not doing any heavy animation, but the frame rate stays near 50 when the cursor is over any window. The screens I tested on have column headers in a grid that "highlight" and buttons that change color and appearance when scrolled over. Even moving the mouse on blank areas of the windows cause the same Frame rate and CPU usage (doesn't seem to be related to these minor animations).
(Also, I am unable to figure out how to get anything but the two default tools--Perforator and Visual Profiler--installed into the WPF performance tool. That is probably a separate question).
I also have Redgate's profiling tool, but I'm not sure if that can shed any light on rendering performance.
So, I realize this is not an easy thing to troubleshoot without specifics or sample code (which I can't post). My questions are:
What are some general things to look
for (or avoid) in the code to improve
performance?
What steps can I take using the WPF
performance tool to narrow down the
problem?
Is the PC spec listed above (Intel Celeron 1.80GHz with 2GB RAM) too slow to be running even vanilla WPF applications?
Are you applying any BitmapEffect-s to your UI elements?
They are not handled by GPU, so CPU takes care of rendering them. If not used properly (e.g. having a OuterGlowBitmapEffect applied to a large complex element) they can have terrible impact on performance.
Also, you still might want to try profiling your app with a performance profiler. Just to see if it's not your code that causes this.
This is not normal for WPF - I'd suspect one of your developers has written code that runs a timer in the background (or more likely given your description, a mouse move handler) which is affecting the UI in some way.
If you have ANTS performance profiler (it's really nice) I'd run that over your app and reproduce the problem.
Once you've done that, ANTS should tell you fairly quickly what the problem is.
If ANTS doesn't reveal anything at all, and shows you that in fact none of your code is running during this time, then I'd suspect buggy graphics card drivers.
You can test for this by disabling hardware acceleration by setting the following registry key, and trying again:
HKEY_CURRENT_USER\Software\Microsoft\Avalon.Graphics\DisableHWAcceleration to 1
Note: the DisableHWAcceleration value should be a DWORD
I've asked a question about my memory management problem in WPF, but this is a different one about the same problem.
I am using DotTrace trying to figure out what's going on. When I start up my app, I can see in Task Manager that it is taking 200MB. DotTrace says a total of 33MB. If I simply minimize the window and bring it back up, the memory footprint according to TM is about 25MB.
I have a ListBox that shows peoples names and pictures. It shows up to 3000 people (I will work on paging, but that's not the point here). As I scroll down, I can see in TM that the memory increases rapidly. If I just keep scrolling up and down memory quick gets to 1GB. During the scroll there are no changes to the underlying data and there are no events of my own. If I minimize the window and bring it back up, memory drops from 1GB to 25MB.
Before minimizing and seeing the memory go down in TM I took a snapshot with DotTrace and it shows the same amount of memory as before the scrolling - around 30MB or so.
Can someone please explain to me what happens to memory when the app is minimized? Is the figure shown in Task Manager to be trusted?
Thanks
PS1:
There's no change in behavior if I do or don't add this to my ListBox:
VirtualizingStackPanel.IsVirtualizing="True"
VirtualizingStackPanel.VirtualizationMode="Recycling"
PS2:
I've put a button with the code, and the GC doesn't reclaim much if anything(it drops from, say 700MB to 680MB):
GC.Collect();
GC.WaitForPendingFinalizers();
Can't give you a definitive answer, but some things to point out:
DotTrace only shows managed memory usage. It looks your app is using large amounts of unmanaged memory (possibly allocated by WPF itself for all those images).
Minimizing a process doesn't generally free any memory, it just pages it out so it can be used by other applications. It's a red herring in this case.
Look into how .Net's generational garbage collection works.
Until your process reaches the resource limits set by the OS it will not necessarily release any memory it has allocated to it.
Use the Performance Counters built into Windows. They will show you a more useful overall breakdown of your app's memory than DotTrace, including managed and unmanaged memory.
DotTrace sucks. Get ANTS or something. I love ReSharper, but Jetbrains really shouldn't charge for DotTrace, it's woeful.
Edit: 4) is a bit misleading - .Net's memory manager can release memory for other reasons (when a generation is full, for starters).
If you are using a Virtualizing container, the visual objects will be created dynamically as you scroll around. This will in turn could cause a bit of havok with the GC since you are creating rather chunky objects very quickly. Once you minimize, I would assume that the GC is kicking in and collecting all those visual objects.
EDIT:
After seeing your edit, you might want to try setting the IsVirtualizing to false for testing. The default value is true, so omitting it would not change anything.