Re: memory usage minimized



"Alvin Bruney [MVP]" <some guy without an email address> wrote:
how do u trim ur working set at strategic times?

We know the areas that tend to dramatically expand the working set size, so
we trim it just after those events. For example (this is for an Instant
Messaging Client):
- After login (or logout) is complete
- After we create a new Chat Form (aka: Tab Page)
- When a Tab Page is Closed (aka: a Conversation is closed)
- When the user changes options or settings
- When the user hits "Clear All" in a Chat Window

There are a few other areas, but these are the big ones. In general, we
attempt to shink the working set after we do events that we expect to have a
signifigant impact on it.

With these calls in there, the application tends to hover (in the Task
Manager, which is the only thing that matters) around 10 to 20 megabytes of
memory. If we're really agressive about things (using a timer etc) we can
get it lower, but there is then a noticable impact on application
performance.

If we remove these calls completly, after the app has been running for 4 or
5 hours (it's an IM client, remember, so it runs all day long on the
desktop) the memory usage hovers in the 200 to 300 megabyte range, and will
sometimes go higher.

... and before you ask, we're not leaking memory. The application has been
profiled a number of times with both performance and memory profilers and
things look pretty good.

The interaction between .Net WinForms applications and the Win32 Memory
Manager seems (to me) one of the weakest areas of the overall platform. Any
signifigant (any many insignifigant) application ends up taking hundreds and
hundreds of megabytes of memory, even though they're not doing anything with
it. This is frustrating for developers and users alike, and just plain
shouldn't be happening on a platform as mature as this.

--
Chris Mullins, MCSD.NET, MCPD:Enterprise, Microsoft C# MVP
http://www.coversant.com/blogs/cmullins


.



Relevant Pages

  • Re: Still confused why working set larger than virtual memory
    ... With the SysInternals Process Explorer the column is called Working Set. ... What you removed is exactly the "smart trick" to have memory "accessible", ... as you map views you never unmap. ... I attach my test source which I used for my file mapping measurements. ...
    (microsoft.public.vc.language)
  • Re: Binary data in multiple adjacent files
    ... Mapping it doesn't eat any working set except, possibly, for the ... It's not faulted into physical memory. ... You also get a whole "page fault cluster" faulted in. ... grid sections immediately north, south, northeast, northwest, southeast ...
    (comp.os.vms)
  • Re: Still confused why working set larger than virtual memory
    ... The next time I map the same part of the file, it still contains the same data I filled it before, demonstrating it resided somewhere (I also explained why I am sure they resided in the physical memory, not in the page file). ... This also exactly what Alexander Nickolov is talking about: even when you unmap your file views, the pages still may reside in the memory and may be a part of the working set. ... I am not freeing the memory, I am only unmapping its virtual addresses. ...
    (microsoft.public.vc.language)
  • Re: Still confused why working set larger than virtual memory
    ... > when working set is larger than virtual memory? ... > I think in your below case, you mentioned the file map pages are not counted ... I can see very little memory reported as a working set ... I suppose file pages which are currently mapped into a view are counted as a part of both the working set and used virtual memory, however I did not perform any experiments in this sense. ...
    (microsoft.public.vc.language)
  • Re: CListCtrl memory leak?
    ... I've been unable to find any memory leaks, ... linear growth that drops off precipitously at the time I ... What you described looks like process working set growth. ...
    (microsoft.public.vc.language)

Loading