"Totally invalid", Dean? I'm surprised you didn't throw in "neener,
neener" too.

Kernel32.dll is loaded in all Win32 processes. Psapi.dll is loaded in
only a handful of processes on my XP machine, and it's not loaded by
default into .NET processes. Using psapi.dll introduces a gratuitous
reference to a DLL that few processes would otherwise be using, thereby
increasing the working set, which, by definition, we want to avoid.

Secondly, this may be a .NET list, but some of us still care about
downlevel platforms.

Thirdly, flbbppt to you!

--
/George V. Reilly  [EMAIL PROTECTED]
http://www.georgevreilly.com/blog
If you can, help others.  If you can't, at least don't hurt others.
-- the Dalai Lama
(Get Witty Auto-Generated Signatures from http://SmartBee.org)




Wilson, Phil D wrote:
The story on psapi is that it wasn't installed by default on NT4
systems, so it was in the 1.x frameworks because the 1.x frameworks were
supported on NT4.  The 2.0 framework installs on systems where psapi.dll
is part of the kernel (it's a Windows Protected File), and psapi.dll is
not in the 2.0 framework redist because it doesn't need to be.

But psapi.dll will be there on the system anyway, so EmptyWorkingSet and
SetProcessWorkingSetSize will both work.

Phil Wilson

-----Original Message-----
From: Discussion of advanced .NET topics.
[mailto:[EMAIL PROTECTED] On Behalf Of Dean Cleaver
Sent: Wednesday, January 25, 2006 1:23 AM
To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM
Subject: Re: [ADVANCED-DOTNET] Visual Studio 2005 consumes ALL computer
memory (RAM and virtual)

George,

Given that PSAPI is part of the .Net Framework 1.0, 1.1 and I presume
2.0 as well, and this is a .Net list, then your argument is totally
invalid.

I stand by my original post... That EmptyWorkingSet is indeed a correct
and valid way of doing this.

Dino

-----Original Message-----
From: Discussion of advanced .NET topics.
[mailto:[EMAIL PROTECTED] On Behalf Of George V.
Reilly
Sent: Wednesday, 25 January 2006 21:30
To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM
Subject: Re: [ADVANCED-DOTNET] Visual Studio 2005 consumes ALL computer
memory (RAM and virtual)

SetProcessWorkingSetSize lives in kernel32.dll, a core Windows DLL.
EmptyWorkingSet comes from psapi.dll, which is not present by default on
older versions of Windows.

--
/George V. Reilly  [EMAIL PROTECTED]
http://www.georgevreilly.com/blog
The best rule of friendship is to keep your heart a little softer than
your head.
 -- George Santayana
(Get Witty Auto-Generated Signatures from http://SmartBee.org)




Dean Cleaver wrote:

Phil has "one way" of doing it. EmptyWorkingSet actually only requires



a process handle, and automatically passes in -1 one for the next 2
parameters for you.

But if you really feel the need to pass the extra -1's then yes -
SetWorkingProcessSize is the better option for you.

Dino

-----Original Message-----
From: Discussion of advanced .NET topics.
[mailto:[EMAIL PROTECTED] On Behalf Of George V.
Reilly
Sent: Wednesday, 25 January 2006 19:44
To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM
Subject: Re: [ADVANCED-DOTNET] Visual Studio 2005 consumes ALL
computer memory (RAM and virtual)

Phil has the right of it. SetProcessWorkingSetSize(hProcess,
(SIZE_T)-1,
(SIZE_T)-1) is a moderately well-known trick for making desktop apps
be better citizens.

--
/George V. Reilly  [EMAIL PROTECTED]
http://www.georgevreilly.com/blog



Wilson, Phil D wrote:


I always thought it was  SetProcessWorkingsetSize (process handle,
-1,
-1) ...... Same effect I'm thinking.

Phil Wilson

-----Original Message-----
From: Discussion of advanced .NET topics.
[mailto:[EMAIL PROTECTED] On Behalf Of Dean
Cleaver
Sent: Tuesday, January 24, 2006 11:40 AM
To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM
Subject: Re: [ADVANCED-DOTNET] Visual Studio 2005 consumes ALL
computer memory (RAM and virtual)

It's a very old Windows trick. Basically, all it's doing is calling
"EmptyWorkingSet" on minimise - you can call those APIs yourself if
you want to. I do in my projects, especially the ones that work on
Terminal Services.

[DllImport("psapi.dll", SetLastError=true)] private static extern int



EmptyWorkingSet(IntPtr Process);

Dino

-----Original Message-----
From: Discussion of advanced .NET topics.
[mailto:[EMAIL PROTECTED] On Behalf Of Georg
Jansen
Sent: Wednesday, 25 January 2006 08:35
To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM
Subject: Re: [ADVANCED-DOTNET] Visual Studio 2005 consumes ALL
computer memory (RAM and virtual)

The same happens with Excel, maybe some new coding standard in
Redmond...?
btw: The wm size is not reduced much.

Regards
Georg
www.l4ndash.com - Log4Net Dashboard


-----Original Message-----
From: Discussion of advanced .NET topics.
[mailto:[EMAIL PROTECTED] On Behalf Of Vince P
Sent: 24. januar 2006 20:18
To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM
Subject: Re: [ADVANCED-DOTNET] Visual Studio 2005 consumes ALL
computer memory (RAM and virtual)

I can't stop minimizing and restoring.  It's crazy.




-----Original Message-----
From: Discussion of advanced .NET topics.
[mailto:[EMAIL PROTECTED] On Behalf Of Julia
Lerman
Sent: Tuesday, January 24, 2006 1:21 PM
To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM
Subject: Re: [ADVANCED-DOTNET] Visual Studio 2005 consumes ALL
computer memory (RAM and virtual)

Hey, what an insane but great trick. I was watching my own devenv
hang



out at about 279,000 k and it just went down to 27K after

minimizing.

I'm still biting my tongue over the "just change everything to C#"
"solution"....

julie lerman

-----Original Message-----
From: Discussion of advanced .NET topics.
[mailto:[EMAIL PROTECTED] On Behalf Of Vince P
Sent: Tuesday, January 24, 2006 1:51 PM
To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM
Subject: Re: [ADVANCED-DOTNET] Visual Studio 2005 consumes ALL
computer memory (RAM and virtual)

That's a good trick.. I just did that and my memory consumption went



from 189MB of RAM to 17MB.





-----Original Message-----
From: Discussion of advanced .NET topics.
[mailto:[EMAIL PROTECTED] On Behalf Of Peter
Ritchie
Sent: Tuesday, January 24, 2006 11:56 AM
To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM
Subject: Re: [ADVANCED-DOTNET] Visual Studio 2005 consumes ALL
computer memory (RAM and virtual)

Try minimizing Visual Studio then restoring to see if the



memory usage



goes now noticably when you find its memory usage to be high.


On Tue, 24 Jan 2006 18:32:46 +0100,



=?ISO-8859-2?Q?Stanislav_Pe=BBko?=



<[EMAIL PROTECTED]> wrote:




Hello all.

I have a quite big probelm with Visual Studio 2005. I



program in Visual



Basic and VS consumes all my memory, both RAM and virtual.



I monitor



devenv.exe process in Task Manager. When I start VS and load



a solution



(it's not so big), it occupies aproximatly 130 MB of RAM and



the same



amount of virtual memory. As I work, both of them goes up.



And I do



just simple things .. say I have 4 tabs with source code



opened and I



edit one of them. Occupied memory raises and very soon (up



to 1 hour)



the devenv.exe process has all RAM memory (I have 512 MB in



system and



the process takes cca 350 MB) and even all virtual memory



(about 1 GB).



I have to turn VS on and off, because otherwise it crashes.



:-( I don't



need to say you that work is very slow and restarting VS



is annoying.



At home I have the same problem with Visual Basic 2005 Express.


Did anybody encounter this problem? Thanks a lot for any response.



Some technical info:

Visual Studio: VS 2005 Professional Edition, Version 8.0.50727.42
Framework: 2.0.50727
Language: Visual Basic

Hardware: AMD Sempron 2800+ (2 GHz), 512 MB RAM



Stano


PS: Well. I know, 512 MB of RAM is not too much fo VS and



very soon I



will get 1 GB, but I don't thing that it will solve my problem.

===================================
This list is hosted by DevelopMentorR  http://www.develop.com

View archives and manage your subscription(s) at



http://discuss.develop.com

===================================
This list is hosted by DevelopMentorR  http://www.develop.com

View archives and manage your subscription(s) at
http://discuss.develop.com



===================================
This list is hosted by DevelopMentorR  http://www.develop.com

View archives and manage your subscription(s) at
http://discuss.develop.com

===================================
This list is hosted by DevelopMentor.  http://www.develop.com

View archives and manage your subscription(s) at
http://discuss.develop.com



===================================
This list is hosted by DevelopMentor.  http://www.develop.com

View archives and manage your subscription(s) at
http://discuss.develop.com

===================================
This list is hosted by DevelopMentor(r)  http://www.develop.com

View archives and manage your subscription(s) at
http://discuss.develop.com

===================================
This list is hosted by DevelopMentor(r)  http://www.develop.com

View archives and manage your subscription(s) at
http://discuss.develop.com

===================================
This list is hosted by DevelopMentor(r)  http://www.develop.com

View archives and manage your subscription(s) at
http://discuss.develop.com




===================================
This list is hosted by DevelopMentor(r)  http://www.develop.com

View archives and manage your subscription(s) at
http://discuss.develop.com

===================================
This list is hosted by DevelopMentor(r)  http://www.develop.com

View archives and manage your subscription(s) at
http://discuss.develop.com




===================================
This list is hosted by DevelopMentor(r)  http://www.develop.com

View archives and manage your subscription(s) at
http://discuss.develop.com

===================================
This list is hosted by DevelopMentor(r)  http://www.develop.com

View archives and manage your subscription(s) at
http://discuss.develop.com

===================================
This list is hosted by DevelopMentor®  http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com



===================================
This list is hosted by DevelopMentor®  http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com

Reply via email to