WPF Memory Usage
- Just wondering....
Is a compiled MSbuild WPF app supposed to be 20mb resident. - I find this tobe ridiculously huge considering all I have on the screen is a window and a button - without any styling. I understand that my exe is only 50Kb -probably cause it's only a script. I mean I added a couple of extra controls and something with a Tab interface with two pages loaded rises upto 50Mb resident.
If I could pose to any-one that could inform me of a way of removing the clutter - could I perhaps limit the necessary object instanced to save on runtime memory. ,eg. use onover images as butons instead of the SVG buttons. -I understand that this is not what WPF is supposed to be all about, but If I am to make an app that runs on existing hardware, and if I were to deploy it over WPF/E - I have to account for the computers that can't handle 100Mb worth UI.
Any tips would be nice.
Todas as Respostas
First, you'll find wpf/e doesn't have the same footprint as WPF, as it's a completely different implementation.
Secondly, memory footprint is like performance testing, without numbers I don't foresee any issues in what you're seeing. Is there memory pressure on your machine? Is the CLR put into a situation where it needs to give back memory? Are there an unusual amount of allocations as you add complexity to your application or are you paying the initial cost you chose to make by choosing a manged evironment, aka CLR, garbage collection, memory allocations, frameworks, etc.
My advice would be that if you're dealing with machines that can't handle a 100Mb UI, stay away from WPF. And from web based solutions as well (dhtml gets hungry fast). And I'd really advise not relying on a managed runtime if memory footprint is really that important.
I'd answer more on the optimization side of things, checking generation sizes, events, etc, but I don't think this is a real issue, more a choice of toolkit you want to use.
As a side note, keeping vectors in memory is probably going to take less space than graphics. Oh and it's XAML, not SVG.
- What ever - Scalable Vector Graphics as a part of the Xaml - just more complex (ie usable and inheritable by all objects)
Managed/Unmanaged - I didn't know you could compile #code using Framework elements Unmanaged - Doesn't that need headers and such and done in a fully compiled language like C/C++ ? or at least #code not using the Framework? (ie doesn't the Framwork rely on it)
WPF/E and WPF have a difference ? - I found that any UI content that I make up in WinXaml will display in the WPF/E engine - not sure if the animation side of things is only a subset, I'm pretty sure WPF/E is nothing like Flash - especially on the Processor and Memory usage side of things. , I beleive this will be it's major drawback in adoption by the Handcoding community. -Flash was inaccessible by us - but now all VistaPC's will be able to display custom UI's that maybe handwritten, which is it's strong selling piont -A everyone has it and B everyone can write it, unlike the adoption of the Gecko framework which only a select few have it installed. -oh and C. that it's the same as Msoft EXE deployments.
-anyway I tried changing settings to compile to X86 only - no difference(slightly improved load time but memory foot print the same) I believe you should research these topics a bit more.
SVG and XAML are different beasts, the first is a standardized xml based vector language, the second one is an object tree building language that happens to be used by WPF, WF, and a few other languages.
Using WPF requires using a managed language and as such will always have a bigger memory footprint than a native application built with MFC/C++. I'm suggesting that if your requirements are to keep memory usage / working set to a minimum, you should stick to unmanaged languages like C++.
WPF/E is called Windows Presentation Foundation / Everywhere, and is a plugin for browsers that support a subset of WPF, and run on mac os x Safari, windows IE and firefox. It is a completely different beast from WPF itself. WPF/E is very much like flash in its capabilities, a portable vector graphics system that supports animations, audio, video, and does plenty of things better with full scripting and later in the year CLR support for managed languages. It is a different product to WPF, and i'm sure a query on google will give you plenty of information to research the pros/cons of the two technologies.
As for Vista, you're right that the deployment of .net 3 on these machines will be a good thing for WPF adoption.
I still don't believe you have a real memory problem, but more of a "taskmanager syndrome". That said, I don't see a 100Mb of memory usage on a simple application, I see it on our current application that renders many controls, many usercontrols and many graphics, and way too many databindings for our own sake.
- SVG - acroynm Scalable Vector Graphics ,, Xaml button is inherited from GDI.rectangle.roundcorners as a Scalable vector graphic
SVG button =
<rect w imes h />
<eventonover = script />
Xaml Button =
new button : Drawing.Rectangle
+= event - onmouseover.
-really WPF's Xaml is just super SVG ,XUL etc all combined (ie the .net framework instead of gecko+svg)
Hmm so to write programs that have the fancy stuff yet still workable on old hardware I have to still learn C - I thought so, new I can't just get away with VB! - but I have been looking into using the Dispose method on me Framwork objects - maybe there is the possibilty of using higher elements in the tree of the framwork without introducing all the sub inherited classes which come with the instance of for example a button. -but then why bother using WPF.
So WPF/E is really only a subset - the fancy stuff only! - Shame that is - would be really cool to have the full .net framwork on the clients machine at your disposal (I think Msoft will probaly end up doing that anyway though - will probably end up making somesort of permission table for the .net framework elements while exposed to Xaml scripts from external sources)
-It's not task manager syndrome - it's 20mb for 1 Xaml c# compiled window - try it out ,, I presume when the window is instanced it loads everything from PresentationCore to System.Windows and so forth (there are alot more Namespace references necessary for a .net3 window than a .net2 -3 must have a damn lot of runtime object instantiation just to popup a window)
Run the Windows SDK SdkViewer - it drops to to about 57mb resident once loaded and not being used...jumps to 66mb if there is another tab open, 73mb when a third is open (meaning that there must be around 10mb of new objects for a simple 100kb of Xaml<FlowDocument>.content.text [although I'd say it's probably less than that - i haven't counted the chars!]) -are fonts being rendered as stroked vector paths? -if this is the case for a simple example application, how much ram does office2007 chew on? -is each document paragraph in memory counted as megabytes, and pages in decabytes - how r u supposed to display a 1000 page document (that's 10mb * 1000 = alot).
...now I don't wanna blow any whistles about any competing frameworks-but as I am typing this I am runnig Firefox which is just a compiled Gecko Xaml/??++ and it's 100mb with raster styling(yes alot less than the SVG styling WPF uses inherently so memory saving is expected and I presume they used fully compiled code).
Anyway I know the new computers are going to have Flash hardrives and ram measured in Gigabytes so I guess it wont be a problem on those machines.
-I guess as usual, we all have to upgrade.
(I am not being angy (not alinux wannabe) just hoping Msoft is listening and thinking about the Little old granny that accidently stumbles upon a WPF/E website, installs the necessary stuff and thier computer just stalls becuase of it - we all know flash don't come with ur computer but everyone installs it, and it works well even on old hardware)
-I'll install WPF/E on an old p3 to see what happens - hopefully I am surprised and rewrite me website(s) , I'll post the result. By task manager syndrome, I mean the following: What is the issue with a program eating up memory you're not using? Performance wise, it's better to allocate the data and reuse it as needed rather than give it back to the os and try to allocate it later. The CLR is memory hungry but will release memory when there's real memory pressure.
Hence my comment that your problem doesn't exist, because you only see memory being used that is not used otherwise in a system that still has memory, and hence no reason for the CLR to give any memory. The real issue at stake is not the performance of the application, the customer scenario, or a specific issue, but just the aesthetics of a number in an application called the task manager. Hence why I call this the task manager syndrome.
As for the example you give at the beginning of your message, I'm completely at loss as to what it could be. Drawing.Rectangle? onmouseover? Saying xaml is like svg is like saying that gdi+ is like xaml. They both do rectangles in vectors, but i'm at loss to find any other connection. And finally, no the rectangles in xaml are not done through gdi.
I'll finish by repeating once again that WPF/E for granny doesn't hae the same implications in term of footprint on the machine as WPF. WPF/E is very much optimized to use less memory.
I'd suggest you ordered one of the excellent books on WPF, the Petzold or the excellent WPF Unleashed from Adam Nathan's, or of course the oreilly by chris sells and ian griffiths (although it's a bit outdated, but they're both working on the next version). You'll find plenty of content to understand what WPF is, how to use it, and what are the implications in term of performance / memory.
- found out about some thing called NGEN
Native image generation - Used to turn JIT CLR into native code.
-The service probably runs by default on Vista Machines - therfore making your apps run faster the second time.
-On xp you have to download it.
Or apparently you can just run it on your app, and if you believe all the PC's your distributing too are the same - hopefully it would be a typically compiled app -which runs faster than a CIL app. - Whoops Ngen is a part of .net framework - you can just run Ngen when your deploying your app -cool.
Although I have been reading that it may not always help in speeding up the app
Msoft will probably one day make this an automated process, whereby Ngen runs on its own when it sees a new application. - It's so annoying when someone asks a simple question and gets a lecture in return from someone who doesn't even begin to answer the original question.
I agree the 20+ meg footprint seems large to me as well. I am seeing the same issue. If anyone could enlighten me as to why this is the case, I would appreciate the knowledge. My clients look at the memory footprint in task manager from time to time and get alarmed by the amount of memory being consumed. Regardless of my explanations regarding managed environments (they don't care) the amount of memory still available on their machine (still don't care) they consider it a bug in the software. It would be helpful to have a better explanation if only for my own understanding.
Or better yet, it would be great to find a way to optimize my application to use less memory if there are some simple ways. Isn't this the nature of good programming? - I think SerialSeb gave a great answer: Task Manager Syndrome
The task manager is not a reliable source for how much memory a managed application uses. Minimize the window and see how much memory it uses. This article does a good job explaining: http://www.itwriting.com/dotnetmem.php If your customer's are being anal about the "task manager memory usage", look into the SetWorkingSet method.
Silverlight (aka WPF/E) is not the "same" as WPF, just as SerialSeb explained. It's a different runtime, different renderer. It only similarity with WPF is it's API and it's framework concepts.
NGEN will do nothing for you with Silverlight. NGEN generates a native assembly and installs it in cache in the local machine. The most this will do for you with a .NET application is "maybe" speed up load times. .NET assemblies are JITed at launch, generating and executing native code on demand.
Yes, Silverlight does not have the full .NET runtime, but it does not need it. It is a small download and if it contained the full .NET framework, a casual web browser would need to download up to ~200 megs. In that case, why not just make an XBAP application?
In the case with WPF, don't expect to write next generation software that runs on last generations hardware...
(BTW, Silverlight runs just fine on my 1ghz pico-itx with 256 megs of RAM -- Just like grandma uses.)
-Jer
