Regards,
a .net service novice.
Nick Wienholt, MVP
Maximizing .NET Performance
http://www.apress.com/book/bookDisplay.html?bID=217
Sydney Deep .NET User Group www.sdnug.org
"Matt Pallatt" <matt.p...@bnm.co.uk> wrote in message
news:%23PXNPlq...@TK2MSFTNGP10.phx.gbl...
If you need to trim the amount of RAM used (which is probably not the case),
you can save some by pre-JIT'ing all the assemblies used (NGEN them). This
will prevent the JIT compiler from being loaded.
-mike
MVP
"Matt Pallatt" <matt.p...@bnm.co.uk> wrote in message
news:%23PXNPlq...@TK2MSFTNGP10.phx.gbl...
Note that your app isn't necessarily using 16 megs at the moment - just
that it did at one time (during loading, most likely). Pre-JITting your
assemblies won't help much. What the tool you're using is listing is
working set size, which is managed by the OS, and will be trimmed when
the OS feels like it. For a windows forms app, it trims it when your app
is minimized. The working set size doesn't necessarily correspond to
memory in use, just memory that can be allocated without going to the OS
for more. You can trim your WSS by using methods provided in the
System.Diagnostics.Process class.
Mark
> What the tool you're using is listing is
> working set size, which is managed by the OS, and will be trimmed when
> the OS feels like it. For a windows forms app, it trims it when your app
> is minimized.
> The working set size doesn't necessarily correspond to
> memory in use, just memory that can be allocated without going to the OS
> for more.
This last statement is not quite true. Without going into details, in NT the
working set of a process is the subset of virtual address space that is
currently resident in physical memory. It roughly corresponds to the number
of pages the application touched recently.
> You can trim your WSS by using methods provided in the
> System.Diagnostics.Process class.
You can do that but it's not recommended.
--
Regards,
Alvin Bruney
Got tidbits? Get it here...
http://tinyurl.com/3he3b
"Pavel Lebedinsky" <m_pll ./. hotmail ./. com> wrote in message
news:O2ZKTZJ3...@TK2MSFTNGP11.phx.gbl...
> Pavel,
> can you go into all the details, or point me to a link. don't just
> tease me like that
>
> > Without going into details, in NT the working set of a
> > process is the subset of virtual address space that is currently
> > resident in physical memory. It roughly corresponds to the
> > number of pages the application touched recently.
I don't know all the details. I also don't think this stuff is really
documented anywhere.
According to a dev at MS, working set in NT is a kernel data
structure which contains what memory manager decides it
should contain. The details change from release to release as
well as the state of the system.
Things like page table pages and data structures used to
manage the working set are not part of process virtual space
but they are still counted in the working set. So in theory it's
possible (though very unlikely) that working set can even be
larger than virtual bytes by some small amount.
(You can see these pages in the output of vadump -o -p <pid>
as Page Table Pages and Other System).
Another interesting aspect of the current behavior is that
if you map the same physical page twice at different
virtual addresses and then touch both virtual pages,
they both will count against your working set even
though they're just different views of the same memory:
http://weblogs.asp.net/greggm/archive/2004/01/19/60078.aspx
> "Mark" wrote:
>
>> What the tool you're using is listing is
>> working set size, which is managed by the OS, and will be trimmed
>> when the OS feels like it. For a windows forms app, it trims it when
>> your app is minimized.
>
>> The working set size doesn't necessarily correspond to
>> memory in use, just memory that can be allocated without going to the
>> OS for more.
>
> This last statement is not quite true. Without going into details, in
> NT the working set of a process is the subset of virtual address space
> that is currently resident in physical memory. It roughly corresponds
> to the number of pages the application touched recently.
>
Yes, thank you for the better explanation.
>> You can trim your WSS by using methods provided in the
>> System.Diagnostics.Process class.
>
> You can do that but it's not recommended.
>
Definately not. It won't help, because, as has been said so many times
before, the WSS isn't an indicator of how much memory your app is
currently using. It's just to make (some) people feel better. It will
almost certainly lead to poorer performance.
Mark