|
The .NET GC is self-tuning. It runs on both a semi-regular (self-adusted) schedule and on-demand when either the applications calls for it or the operating system does and wants memory returned. Memory is never released "improperly" as you call it. The GC tries, and does a very good job, at keeping a resonably sized pool of memory available to the application for future allocations. Like I said, the GC is self-tuning and can only improve it's allocation strategy by over-estimating what it needs to start with then watching how your application allocates and releases memory.
But, yes, the GC is a bit lazy when application activity is low, and for good reason. In order for the GC to run, the threads of your application must be stopped before the collection takes place. This is because objects in memory can be moved by the GC to compact and defrag the heaps and pointers to those objects must be updated to reflect their new locations. This cannot be done while the code is still running! So, yeah, the GC tries to be as lazy as possible, giving your app more time to execute.
Garbage Collection and object allocation, when dealing with the Managed Heap, goes VERY, VERY fast. It slows down considerably if memory has to be allocated from the system first, adding it to the Managed Heap.
BTW, this is all documented on MSDN:
Programming for Garbage Collection[^]
Garbage Collection: Automatic Memory Management in the Microsoft .NET Framework[^]
Garbage Collection—Part 2: Automatic Memory Management in the Microsoft .NET Framework[^]
Improving .NET Application Performance and Scalability[^]
RageInTheMachine9532
"...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
|
|
|
|
|
Hi Sarab,
I think that your problem is regarding the number of handles you create!!! If you know, Windows restricts each process in creating handles. For example, it is 10,000 handles for XP. But my experience says that this equation is that straight forward!!! It is also dependent on the memory the process occupies and the number of GDI objects being created by your app.
To confirm this, try seeing the number of GDI objects and Handles being created by your app through the taskmanager->View->Select Columns... And if the number of Handles is going beyond 500 and GDI objects more than 300 or 400, then i think that you have located the problem!!!
Even i had a similar problem, but not yet found the solution as such!!! The work around which i did was not storing such a huge data in memory which creates lots of GDI objects!!!! Though im able to get control over it, i feel that this is not the correct solution to it!!!
Regards,
Rajesh
|
|
|
|
|
Thanks folks!! I appreciate everyone's help...
Turns out, I didn't have to cross the Seven Seas:
I managed to solve the issue by explicitly disposing (Image.Dispose()) some images I was creating during processing... I used to think that .NET automatically clears the memory being held by an image object once all references to it are removed - Guess that isn't the case...
Learnt a lot from these discussions though - Thanks!
-- modified at 16:03 Friday 3rd February, 2006
|
|
|
|
|
I have a .Net application which at one point repeats a task several times. Each time the task is performed, it pops up a progress window, updates the window while working, and then closes the window.
This should all work fine, but what I am finding is that if I have a loop that repeats the task 5 times, the progress windows get displayed and updated, but the screen doesn't seem to redraw the parent window after they are 'closed', thus it looks as though all windows remain open until the last task completes, at which point the screen redraws, and correctly see that all windows have been closed.
Is there a function that I can call to ensure that all window events take place and the screen redraws after each task completes? I have this problem in several spots where a parent window calls a computation intensive task, and then does not get redrawn correctly until the task ends.
Thanks in advance for any pointers,
Spencer
|
|
|
|
|
If you call the Invalidate() method of the control which isn't redrawing properly, followed by Application.DoEvents(), this should force the control to process its pending events and redraw.
If you're doing process intensive stuff and dont want the application to lock up, then you might want to consider using a seperate thread.
Cheers,
Will H
-- modified at 10:41 Monday 30th January, 2006
|
|
|
|
|
Thanks, this worked perfectly.
In this case, I don't want the user interface to be active, just need the dialogs to clear correctly when finished, so I don't need the seperate thread here.
Thanks again,
Spencer
|
|
|
|
|
Hi,
Can anybody suggest a good .NET Profiler which gives the details of the memory taken up by the application and also regarding the performance details of the application!!!
Thanks anyway,
|
|
|
|
|
|
|
Hey Thanks Buddy.
I had used ANTS Profiler and i found it to be very slow(atleast on my system)... But the other one was a very handy, and it made my life easy!!!
And can i have some dedicated Performance profilers also??
Thanks anyway,
Rajesh
|
|
|
|
|
I'm working with Visual Studio 2003 and Framework 1.1.
Someone tells me that it is possible to install Framework 2.0 SDK and developing applications with Framework 2.0 in Visual Studio 2003.
I've tried to install Framework 2.0 SDK, but the new objects are not visible from Visual Studio 2003 .
Someone can help me  ???
nikolag
|
|
|
|
|
nikolag wrote: Someone tells me that it is possible to install Framework 2.0 SDK and developing applications with Framework 2.0 in Visual Studio 2003.
No, it's not. 2003 will ONLY work with the .NET Framework version 1.1. 2005 will ONLY work with the .NET Framework 2.0.
RageInTheMachine9532
"...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
|
|
|
|
|
ok, now it is clear.
Thank you
"Tutti sanno che una cosa è impossibile da realizzare, finchè non arriva uno sprovveduto che non lo sa e la inventa"
(Albert Einstein)
|
|
|
|
|
hi all,
Recently I devised this bit of code (C#) that works wonders for the memory usage reported in task manager:
Process currentProcess = System.Diagnostics.Process.GetCurrentProcess();
currentProcess.MinWorkingSet = currentProcess.MinWorkingSet;
With one of my more complicated programs, this reduced the initial memory usage (measured once the form loaded completely) from 34690 KB to 8980 KB (!).
I've tried various other solutions, most of which rely on forcing a garbage collection or reducing the process' working set to the minimum working set. I found neither to be very effective. I've never seen this approach anywhere else (small wonder - who would think that setting a value to itself would make such a difference?!).
I haven't had time to research why/how this code works, but this solution changes no values and has an immediate effect (just like minimizing and restoring a .NET program does). Place it in your code after your form initializes and watch your memory usage go down!
Hope this helps someone!
|
|
|
|
|
|
And the working set is precisely what I want to reduce, not just the specific amount that the app is actually using but the entire chunk of memory that the runtime reserves. That's what makes a difference from an outside perspective.
|
|
|
|
|
Maybe, but how much slower is your application when it needs more memory from somewhere and has to ask for more, rather than just use some from its reserve.
ColinMackay.net
"Man who stand on hill with mouth open will wait long time for roast duck to drop in." -- Confucius
"If a man empties his purse into his head, no man can take it away from him, for an investment in knowledge pays the best interest." -- Joseph E. O'Donnell
|
|
|
|
|
Notice though that the runtime has no problem reducing the memory reserve when you minimize and restore an application, so apparently there is an excess available. As discussed elsewhere, at startup the runtime needs a larger amount of memory, but not so much once everything has loaded, so reducing the working set after initialization is a reasonable solution.
|
|
|
|
|
gonzotuna wrote: who would think that setting a value to itself would make such a difference?!
Because your not. You are setting a property. And a property is just syntactic sugar for a specify style of method(s). The getter and setter of a property actually become the methods get_PropertyName() and set_PropertyName(PropertyType value).
ColinMackay.net
"Man who stand on hill with mouth open will wait long time for roast duck to drop in." -- Confucius
"If a man empties his purse into his head, no man can take it away from him, for an investment in knowledge pays the best interest." -- Joseph E. O'Donnell
|
|
|
|
|
I was actually remarking on the fact that the side effect of setting this specific property to itself would be something so drastic/unexpected, not on the fact that setting a property can have side-effects.
I discovered this memory phenomenon quite by accident as I was experimenting, rather than by deducing what methods to call, etc. I haven't taken the time to dig into what's going on under the covers, but I think it's pretty cool and I'm surprised/glad I stumbled upon it. That's all I meant. 
|
|
|
|
|
In the modern age of AUTOMATIC memory management, why is this even a concern?????
Never once have I considered the memory reserved by the framework to be a problem. I've had a few customers ask, and with a quick explanation of how the .NET Framework starts out reserving more memory than it actually needs for it's self-tuning performance, and releasing it back to Windows when Windows demands it, the issue is dropped.
RageInTheMachine9532
"...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
|
|
|
|
|
However, it seems that initially the .NET framework reserves even more memory than it needs to have in reserve for performance reasons. Ever notice how the total memory usage drops dramatically when minimizing and then restoring? If that caused a drop in performance, then we would have to advise everyone using our software that in order to maximize performance they should never minimize the app, explaining that it's just a quirk of the runtime 
Is this an important issue? Not really, at least technologically speaking. It's just one of aesthetics. And pretty numbers speak loudly, so if I can provide a product that works, performs well, and has lower apparent memory consumption as well, I'm going to. Especially since I can do it (well, the memory consumption thing at least ) with one line of code.
|
|
|
|
|
gonzotuna wrote: Ever notice how the total memory usage drops dramatically when minimizing and then restoring?
We all have. It also just doesn't matter, since when Windows wants the memory back, the runtime is more than happy to return it.
gonzotuna wrote: And pretty numbers speak loudly
Only if the numbers actually mean something. If the customer wants an app based on "pretty numbers", that's a customer I don't want. I deal in meeting the customers functionality requirements, not the b/s they think they want and don't really understand. I don't waste my time "lying" to the customer about the memory requirements of their app. If they're equipment is so tight on memory, it usually means their checkbook is just as tight and their payment will show up 6 months late.
RageInTheMachine9532
"...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
|
|
|
|
|
Once you minimize .NET application or set this property, memory swapped to disk which increase page faults and decrease application's performance. Working set is misleading parameter for .NET applications memory usage.
Read this:
How much memory does my .NET application use?
|
|
|
|
|
I have a Vb Scripting problem with .NET C# application and also
in Asp.NET.
I have written COM component in VC 6.0 , which execute a VBScript
and return a Recordset.
This componet is perfetly working with VC 6 ,VB 6 applications
but it does not work with .Net
the component is which exposes an interface method
GetCustAdoRecordset
{
========= do the script code here
}
CMyScriptSite::public IActiveScriptSite
{
}
..........
iActiveScript->AddNamedItem(L"MyScriptExicuter", SCRIPTITEM_ISVISIBLE
| SCRIPTITEM_ISSOURCE | SCRIPTTEXT_ISPERSISTENT)
.......
this class is my event handling class
CMyScriptExecuter::public CCmdTarget
{
...
...
// here gobal variables are set and passed to the script engine
BEGIN_DISPATCH_MAP(CMyScriptExecuter, CCmdTarget)
//{{AFX_DISPATCH_MAP(CMyScriptExecuter)
DISP_PROPERTY(CMyScriptExecuter, "MycustTime", m_custTime, VT_DATE)
DISP_PROPERTY_EX(CMyScriptExecuter, "TestCount", GetTestCount,
SetNotSupported, VT_I4)
DISP_FUNCTION(CMyScriptExecuter, "mymethod", mymethod, VT_EMPTY,
VTS_BSTR)
...
//}}AFX_DISPATCH_MAP
END_DISPATCH_MAP()
}
The above message map code is not executing while running from .net.
Can u kindly give a solution for this, is it a .net problem or any
thing else
===============================
thomachanpv
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
