WPF RichTextBox memory leak - c#

In my application, I have a lot of RichTextBoxes that are created dynamically in run time. I realized that the application has a memory leak, which is caused by the RichTextBox controls. To prove that the memory leaks because of the control I wrote the following test method:
for (int i = 0; i < 3000; i++)
{
Control rich = new RichTextBox();
pnl.Content = rich;
}
GC.Collect();
GC.WaitForPendingFinalizers();
pnl is a ContentControl that is declared in Xaml code.
If you run the following code, you can see that the memory usage is growing rapidly.
Any ideas how to solve the problem?
I considered creating an object pool, but this would complicate my application, and I rather avoid it.
edit: I've added call to the garbage collector to demonstrate that the objects are not garbage collected - there is no improvement in the memory usage with and without the call to the GC collect method.
Note that calling rich.Dispose within the loop eliminates the memory usage growth.

This isn't an indication that your application has a memory leak, it's an indication that your application is using a lot of memory. It's a leak if the RichTextBox controls don't get released at some point after they've fallen out of scope (detecting memory leaks on managed objects is notoriously difficult and unprovable).
A common misconception that an object falling out of scope will cause it to be garbage collected. This just makes it eligible to be collected. The object may theoretically never be collected until the application terminates. The fact that it grows with RichTextBox and not with other controls is not an indication that there is a memory leak in the RichTextBox, it's just an indication that it uses more memory per instance than other controls. While this information may be useful, it doesn't help when determining whether or not there's a memory leak.

Found this elsewhere, and it seems to be correct as far as my testing is concerned.
When a FlowDocument is created,
relatively expensive formatting
context objects are also created for
it in its StructuralCache. When you
create multiple FlowDocs in a tight
loop, a StructuralCache is created for
each FlowDoc. Let's you called
Gc.Collect at the end of the loop,
hoping to recover some memory.
StructuralCache has a finalizer
releases this formatting context, but
not immediately. The finalizer
effectively schedules an operation to
release contexts at
DispatcherPriority.Background.
So the RichTextBox (or FlowDocument) in case is not leaking just waiting on a background thread to cleanup. When it runs exactly who knows. I wish this just implemented a dispose method that would force a cleanup immediately.

We had the same problem in winforms 2.0 and we had to buy a 3rd party rich text control. I guess that Microsoft didn't bother to fix it...

This fixed the issue to me:
http://blingcode.blogspot.com/2010/10/memory-leak-with-wpfs-richtextbox.html
Basically add two attributes to each RichTextBox :) :)
IsUndoEnabled="False"

Regarding your edit:
You've added the GC calls after the loop terminates and all 3000 RichTextBoxes have been created.
While I agree that it seems odd that the previous one isn't freed inside the loop when it's replaced by a new one, it's such a tight loop that the GC probably isn't getting a chance to "do it's stuff" before the loop terminates.
I don't think it's a good idea (but it should be OK in test code), but have you tried moving the GC calls inside the loop?

Related

High CPU usage after long running

I have an issue with my application hope somebody can give me suggestions how to fix it.
I have multithread application. It tuns 10-20 threads and in each thread I execute some complicated tasks.
Thread thread = new Thread(ProcessThread);
thread.Start();
private void ProcessThread()
{
while(IsRunning)
{
// do some very complex operations: grab HTTP pages. Save to files. Read from files. Run another threads etc.
}
}
At the beginning app uses about 10% CPU and 140Mb memory. But after 1000 executes CPU usage is 25%-30% and memory is 1200Mb. I know that probably I have a memory leak in my code, I will try to fix it. But what happened with CPU? Why it grows? Each execution does the same operations as in the beginning and later (for example open web page, grab some info and save it to the file).
I think that the issue can be with GC. More memory app take, more CPU need to clean the memory?
The other question, could you please advise a good tool how to measure what take CPU in my app?
And maybe you can recommend a good tool to analyze memory and check where it leaks? I tried JetBrains dotMemory but didn't understand much. Maybe you can help me.
Here is the stat:
http://prntscr.com/dev067
http://prntscr.com/dev7a2
As I see I don't have really too much unmanaged memory. But at the same time I see problems with strings, but can't understand what's wrong as GC must clean it?
Appreciate any suggestions and recommendations what I can improve.
Unless you are wrapping native types, I doubt you have a memory leak. The memory usage is most likely due to the way the GC works.
The GC will not collect all dead items in a cycle. It will use generations. That means it will collect older objects only if it needs the space. So the memory usage will increase until the first collection. Then, only a fraction of the items is collected, which will lower memory usage somewhat, but not completely. And the GC will also not necessarily return freed memory to the OS.
In higher editions of Visual Studio you'll find a memory profiler.
It is very unclear what are "some complicated tasks".
And this especially worries me:
// do some very complex operations: grab HTTP pages. Save to files. Read from files. Run another threads etc.
Well, if you are indeed starting new threads from your process thread, then it totally makes sense for CPU usage to raise. From performance perspective creation of new threads is costly, and that is a reason why we use thread pools(recycling threads).
The same goes for memory usage. More threads = more memory required for each thread (each thread has it's own stack requiring additional memory)...
Also, I don't believe that GC is a culprit here.
There is a lot of questions that need te be answered before I can help you find a cause of such a behavior, and before we can blame GC :):
1)Do you start all, let's say, 20 threads at the start of your program?
2)Do you create new threads from already running ones?
3)What is termination condition for those threads? Do they actually terminate?
I would recommend using dotTrace for determining CPU usage.
Unfortunately, I haven't used any tool for profiling memory usage so I cannot recommend any.
I looked at your screenshot and from that I see you have many objects which are surviving generation 0 collection so they are being escalated to generation 1 and then to generation 2. This could be a sign of a memory leak but not necessarily. Without seeing your code it is hard to say. All I can tell is that you are keeping your objects for a very long time. This may be needed but again I cannot tell without seeing the code.
A bit about GC
When the GC wakes up to cleanup, it analyzes the managed heap to see which objects are not rooted and marks them all ready for collection. This is called the mark phase. Then it starts deallocating the memory. This is called the sweep phase. If it cannot clean anything up, those objects go to generation 1. Sometime later the GC wakes up again and repeats the above but this time, since there are items in generation 1, if they cannot be collected they will go to generation 2. This could be a bad sign. Do the objects really need to be around for that long?
So what can you do?
You say the GC must clean stuff. Well yes the GC will clean things but only if you are not referencing them. If an object is rooted then GC will not be able to clean it.
Write Code with GC in mind
To start with the investigation, you need to investigate your code and make sure your code is written with GC in mind. Go through your code and make a list of all the objects you are using. If any object is of a class which implements IDisposable then wrap them in a using statement:
using (Font font1 = new Font("Arial", 10.0f))
{
// work here depends on font1
}
If you need font1 in one of your classes as a class level variable, then you have to make the descision when to call Dispose on it: At the very least this class should implement IDisposable and call dispose on font1. Users of this class (any code which calls new on this class) should either use this class with the using statement or call `Dispose' on it.
Do not keep objects longer than you need them.
Still need more investigation?
Once you have investigated your code and ensured your code is friendlier to the GC and you still have issues then investigate using a tool. Here is a good article to help you with this part.
Some people have the misconception that calling GC.Collect() will solve the memory leak issue. This is not true at all. Forcing a garbage collection will still follow the same rules and if objects are rooted, you can call GC.Collect() indefinitely, the objects will still not be cleaned up.
Here is a sample application which will show this:
public class Writer : IDisposable
{
public void Dispose()
{
}
public void Write(string s)
{
Console.WriteLine(s);
}
}
class Program
{
static void Main(string[] args)
{
Writer writer = new Writer();
writer.Write("1");
writer.Dispose();
// writer will still be around because I am referencing it (rooted)
writer.Write("2");
GC.Collect();
// calling GC.Collect() has no impact since writer is still rooted
writer.Write("3");
Console.ReadKey();
}
}
I can only comment on why you have a CPU issue and not GC.
I suggest you verify that you are creating only the number threads you expect. If you happen to have threads launching threads, it's easy to slip up.
As mentioned in another comment, thread creation and destruction is costly. If you are creating and destroying threads all the time, this will have a notable impact upon your performance.
I suspect the cause of your slowdown is memory thrashing, meaning the amount of memory used by each thread is large enough, and/or the total amount used by all threads is large enough to cause memory pages to be swapped in and out all the time. In certain situations, the processor can spend more time swapping memory to and from disk than it spends executing the thread.
Here are my suggestions:
Use a thread pool. This minimizes the time you need for thread creation and destruction. This will also bound the number of threads you are using.
Make sure each thread executes a reasonable amount of time before it is swapped out -- i.e. you don't have the threads context thrashing.
Make sure the amount of memory each thread is using is not much larger than you expect to prevent memory thrashing.
If you have to use a large amount of memory for each thread, make sure your pattern of usage is such that there isn't a lot of memory paging.
Run you application with "Start collecting allocations data immediately" enabled, get snapshot after a while and look at memory traffic view.
To understand what occupies a memory open "All objects" grouped by type and look what types take the most amount of memory.
For performance profiling I could recommend JetBrains dotTrace (timeline mode, for your case).

Memory Management Ideas?

I'm writing a game in C# with SharpDX...
So, for drawing a frame, currently i'm using a Timer, with interval set to 1;
But this is too slow for a game, so i want something faster...
First of all, if I use another thread for the game (and another for the Window itself) and i use a "[while (InGame)]" statement, it is fast, but the GC will never release a single object, and the memory usage just going up and up...
IF I use the SharpDX built in "RenderLoop" function, it is fast also, but the GC still doesn't do anything...
I've tried to override the Window form "WndProc" function, but the game only refresh itself then i'm moving the mouse like a crazy men...
This is my first real game, with a lot of functions,
so if any of you have any idea, how would i fix it, or what should I use, I would appreciate it...
There must be something in the Window Form lifecycle like a
void FormLife
{
WndProc();
HandleEvents();
etc...
}
(It was just a hard example...)
OR how can i force the GC to do its job, at the end of the while(InGame) state ?
I've tried GC.Collect(); but its dont work...
Don't put your game logic in the UI classes.
Use a multimedia timer and a dispatcher to return to main thread for rendering. From my experience a cycle of 5mSec works well. (Lower will waste CPU time).
Use dispatcher priority of Input so that the timer won't choke the UI and prevent it handling user events.
On timer event, if the previous update hasn't completed, return immediately without doing anything (you can use System.Threading.Interlocked.CompareAndExchange as a cheap sync method).
To make game run faster, try to reuse objects and change their states or to pass short living immutables so that the GC won't delay your program.
Use the IDisposable pattern where applicable.
If GC.Collect does not free memory you have a memory leak. Use the memory profiling tool of your choice to spot the leak (PerfView, Windbg, .NET Memory Profiler, YourKit, ....)
Besides this the best allocation is no allocation at all. If you reuse objects and keep unused objects in a pool you can get rid of GCs almost entirely. Even if you stay away from Gen 2 collections which can block your game for hundreds of ms you also need to keep a sharp eye on Gen 0/1 collections which can also cause noticeable delays.
See http://social.msdn.microsoft.com/Forums/vstudio/en-US/74631e98-fd8b-4098-8306-8d1031e912a4/gc-still-pauses-whole-app-under-sustainedlowlatency-latencymode-despite-it-consumes-025gb-and?forum=clr
You don't typically have to worry about memory management. If you are making sure not to hold on to references then the garbage collector should do its thing automatically based on memory pressure.
You can force it yourself using GC.Collect but you need to be absolutely certain you really need to. Most of the time its not required. Check this thread for more info and points to consider: Best Practice for Forcing Garbage Collection in C#
Since the objects are not being collected you must be holding a reference to them somewhere.
You didn't post much code so it is hard to say where you are holding a reference.
In the past I've used windbg to find the root cause of of memory issues. VS2013 has a memory profiler built in (might be easier to use).
A common case I've seen of holding references is via event subscription. If you have subscribed to any events you have to make sure you unsubscribe to release the object. see Why and How to avoid Event Handler memory leaks? for more details. That doesn't look like your problem.

this.Dispose() doesn't release memory used by Form after closing it.

I have a Windows Form Application in which clicking certain buttons create objects from a 2nd Form. On closing this 2nd Form by the user, the memory used by this form is not released (according to Task Manager).
I tried using this.dispose() on exit button, this.close(), form2 = null in the main code, and tried clearing all controls from this form by code before disposing. None of this has worked and every time the user clicks the button, the memory usage by the application increases and memory used by the previous instance is not released.
What shall I use to solve this problem?
Calling Dispose will not clean up the memory used by an object. Dispose is meant to be used to run user defined code that releases resources that are not automatically released - like file handles, network handles, database connections etc.
The likely culprit is probably the second form attaching events to objects that are outside it (perhaps the first form?) and never unattaching them.
If you have any events in the second form, unattach them in your OnClose override - that will make the second form eligible for garbage collection.
Note, .NET garbage collector is quite unpredictable and it might create a few instances of an object before cleaning up all the older instances that were eligible for collection. A way to know for sure (without resorting to memory profilers) is to put a breakpoint in the finalizer:
public class MyForm : Form {
~MyForm() {
//breakpoint here
}
}
If the finalizer gets called then this class is OK, if not, you still have a leak. You can also give GC a "kick" - but only for troubleshooting purposes - do not leave this code in production - by initiating GC:
GC.Collect();
GC.WaitForPendingFinalizers();
GC.Collect();
Put the above code somewhere that runs after you close and dispose the second form. You should hit the breakpoint in MyForm finalizer.
Dispose isn't for releasing memory - the common language runtime's garbage collector takes care of that. Dispose is for releasing other (non-memory) scarce resources like database connections and file handles.
Generally speaking, you don't need to worry about memory consumption in your .NET applications because the framework does it for you. If you need finer control over memory consumption, you should be developing in a language that provides that control, like C++.
Sounds like the memory is still being used because disposed object have not been reclaimed by the garbage collector. Try using the GC.Collect() static method to force a garbage collection. Watch out for performance issues as this normally halts your program until it has finished.
GC.Collect();
Don't call Dispose() method, call ->>>>> Dispose(true) instead and you will be surprised a lot. It actually freeing memory, you may observe an effect in the task manager.

Garbage collection not functioning as expected

This may likely be an issue with my inexperience using a Managed Language. The issue essentially is a loop within an objects method, which executes over about 20 seconds, throughout the duration of this loop the programs overall memory usage constantly goes up. Now all the variables within the loop which are modified are variables defined within the loops scope (ie. no class members are changed/re-allocated within the loop). After the entire method completes the excess memory is still being used.
I have absolutely no idea why/where this issue is but here are some things which may be a factor:
I use fonts within the loop, but I '.Dispose()' of them and have verified that there is no GDI leak.
I have try/catch statements which are in active use.
Objects are allocated...
So again, any ideas on where this issue may be coming from would be very helpful, I would post code but there is a lot of it. Also as mentioned above the memory is not cleaned up after the method call is done, and even after the object on which the method was invoked has gone out of scope.
Edit
I also just tried the GC.Collect() method, and nothing has changed in the overall result. I have no idea, but does this mean that the memory is not considered 'Garbage'? Again all the allocation is done within the scope of the loop so shouldn't it be considered garbage after the loop terminates. I understand the GC won't immediately get to cleaning it up, but using the GC.Collect() call should force that?
.NET uses traced garbage collection instead of the classic reference counting mechanism.
As soon as your .NET code releases an object or data, it doesn't get cleaned up instantly. It sits around for a while before being cleaned up. The garbage collector is a separate entity wandering around.
Microsoft states about the garbage collector
However, memory is not infinite.
Eventually the garbage collector must
perform a collection in order to free
some memory.
The garbage collector will come around at its own leisure based on complex algorithms. It will eventually clean everything up, if not at the end of the program lifetime. It's not recommended we poke or prod the garbage collector through System.GC members because we're supposed to assume it knows best.
Garbage collector will release objects if there is no pointer pointing to them. Be sure you don't keep not necessary objects in your variables (especially in arrays).

Best Practice for Forcing Garbage Collection in C#

In my experience it seems that most people will tell you that it is unwise to force a garbage collection but in some cases where you are working with large objects that don't always get collected in the 0 generation but where memory is an issue, is it ok to force the collect? Is there a best practice out there for doing so?
The best practise is to not force a garbage collection.
According to MSDN:
"It is possible to force garbage
collection by calling Collect, but
most of the time, this should be
avoided because it may create
performance issues. "
However, if you can reliably test your code to confirm that calling Collect() won't have a negative impact then go ahead...
Just try to make sure objects are cleaned up when you no longer need them. If you have custom objects, look at using the "using statement" and the IDisposable interface.
This link has some good practical advice with regards to freeing up memory / garbage collection etc:
http://msdn.microsoft.com/en-us/library/66x5fx1b.aspx
Look at it this way - is it more efficient to throw out the kitchen garbage when the garbage can is at 10% or let it fill up before taking it out?
By not letting it fill up, you are wasting your time walking to and from the garbage bin outside. This analogous to what happens when the GC thread runs - all the managed threads are suspended while it is running. And If I am not mistaken, the GC thread can be shared among multiple AppDomains, so garbage collection affects all of them.
Of course, you might encounter a situation where you won't be adding anything to the garbage can anytime soon - say, if you're going to take a vacation. Then, it would be a good idea to throw out the trash before going out.
This MIGHT be one time that forcing a GC can help - if your program idles, the memory in use is not garbage-collected because there are no allocations.
The best practise is to not force a garbage collection in most cases. (Every system I have worked on that had forced garbage collections, had underlining problems that if solved would have removed the need to forced the garbage collection, and sped the system up greatly.)
There are a few cases when you know more about memory usage then the garbage collector does. This is unlikely to be true in a multi user application, or a service that is responding to more then one request at a time.
However in some batch type processing you do know more then the GC. E.g. consider an application that.
Is given a list of file names on the command line
Processes a single file then write the result out to a results file.
While processing the file, creates a lot of interlinked objects that can not be collected until the processing of the file have complete (e.g. a parse tree)
Does not keep much state between the files it has processed.
You may be able to make a case (after careful) testing that you should force a full garbage collection after you have process each file.
Another cases is a service that wakes up every few minutes to process some items, and does not keep any state while it’s asleep. Then forcing a full collection just before going to sleep may be worthwhile.
The only time I would consider forcing
a collection is when I know that a lot
of object had been created recently
and very few objects are currently
referenced.
I would rather have a garbage collection API when I could give it hints about this type of thing without having to force a GC my self.
See also "Rico Mariani's Performance Tidbits"
I think the example given by Rico Mariani was good: it may be appropriate to trigger a GC if there is a significant change in the application's state. For example, in a document editor it may be OK to trigger a GC when a document is closed.
There are few general guidelines in programming that are absolute. Half the time, when somebody says 'you're doing it wrong', they're just spouting a certain amount of dogma. In C, it used to be fear of things like self-modifying code or threads, in GC languages it is forcing the GC or alternatively preventing the GC from running.
As is the case with most guidelines and good rules of thumb (and good design practices), there are rare occasions where it does make sense to work around the established norm. You do have to be very sure you understand the case, that your case really requires the abrogation of common practice, and that you understand the risks and side-effects you can cause. But there are such cases.
Programming problems are widely varied and require a flexible approach. I have seen cases where it makes sense to block GC in garbage collected languages and places where it makes sense to trigger it rather than waiting for it to occur naturally. 95% of the time, either of these would be a signpost of not having approached the problem right. But 1 time in 20, there probably is a valid case to be made for it.
I've learned to not try to outsmart the garbage collection. With that said, I just stick to using using keyword when dealing with unmanaged resources like file I/O or database connections.
One case I recently encountered that required manual calls to GC.Collect() was when working with large C++ objects that were wrapped in tiny managed C++ objects, which in turn were accessed from C#.
The garbage collector never got called because the amount of managed memory used was negligible, but the amount of unmanaged memory used was huge. Manually calling Dispose() on the objects would require that I keep track of when objects are no longer needed myself, whereas calling GC.Collect() will clean up any objects that are no longer referred.....
Not sure if it is a best practice, but when working with large amounts of images in a loop (i.e. creating and disposing a lot of Graphics/Image/Bitmap objects), i regularly let the GC.Collect.
I think I read somewhere that the GC only runs when the program is (mostly) idle, and not in the middle of a intensive loop, so that could look like an area where manual GC could make sense.
I think you already listed the best practice and that is NOT to use it unless REALLY necessary. I would strongly recommend looking at your code in more detail, using profiling tools potentially if needed to answer these questions first.
Do you have something in your code that is declaring items at a larger scope than needed
Is the memory usage really too high
Compare performance before and after using GC.Collect() to see if it really helps.
Suppose your program doesn't have memory leakage, objects accumulates and cannot be GC-ed in Gen 0 because:
1) They are referenced for long time so get into Gen1 & Gen2;
2) They are large objects (>80K) so get into LOH (Large Object Heap). And LOH doesn't do compacting as in Gen0, Gen1 & Gen2.
Check the performance counter of ".NET Memory" can you can see that the 1) problem is really not a problem. Generally, every 10 Gen0 GC will trigger 1 Gen1 GC, and every 10 Gen1 GC will trigger 1 Gen2 GC. Theoretically, GC1 & GC2 can never be GC-ed if there is no pressure on GC0 (if the program memory usage is really wired). It never happens to me.
For problem 2), you can check ".NET Memory" performance counter to verify whether LOH is getting bloated. If it is really a issue to your problem, perhaps you can create a large-object-pool as this blog suggests http://blogs.msdn.com/yunjin/archive/2004/01/27/63642.aspx.
I would like to add that:
Calling GC.Collect() (+ WaitForPendingFinalizers()) is one part of the story.
As rightly mentioned by others, GC.COllect() is non-deterministic collection and is left to the discretion of the GC itself (CLR).
Even if you add a call to WaitForPendingFinalizers, it may not be deterministic.
Take the code from this msdn link and run the code with the object loop iteration as 1 or 2. You will find what non-deterministic means (set a break point in the object's destructor).
Precisely, the destructor is not called when there were just 1 (or 2) lingering objects by Wait..().[Citation reqd.]
If your code is dealing with unmanaged resources (ex: external file handles), you must implement destructors (or finalizers).
Here is an interesting example:
Note: If you have already tried the above example from MSDN, the following code is going to clear the air.
class Program
{
static void Main(string[] args)
{
SomePublisher publisher = new SomePublisher();
for (int i = 0; i < 10; i++)
{
SomeSubscriber subscriber = new SomeSubscriber(publisher);
subscriber = null;
}
GC.Collect();
GC.WaitForPendingFinalizers();
Console.WriteLine(SomeSubscriber.Count.ToString());
Console.ReadLine();
}
}
public class SomePublisher
{
public event EventHandler SomeEvent;
}
public class SomeSubscriber
{
public static int Count;
public SomeSubscriber(SomePublisher publisher)
{
publisher.SomeEvent += new EventHandler(publisher_SomeEvent);
}
~SomeSubscriber()
{
SomeSubscriber.Count++;
}
private void publisher_SomeEvent(object sender, EventArgs e)
{
// TODO: something
string stub = "";
}
}
I suggest, first analyze what the output could be and then run and then read the reason below:
{The destructor is only implicitly called once the program ends. }
In order to deterministically clean the object, one must implement IDisposable and make an explicit call to Dispose(). That's the essence! :)
Large objects are allocated on LOH (large object heap), not on gen 0. If you're saying that they don't get garbage-collected with gen 0, you're right. I believe they are collected only when the full GC cycle (generations 0, 1 and 2) happens.
That being said, I believe on the other side GC will adjust and collect memory more aggressively when you work with large objects and the memory pressure is going up.
It is hard to say whether to collect or not and in which circumstances. I used to do GC.Collect() after disposing of dialog windows/forms with numerous controls etc. (because by the time the form and its controls end up in gen 2 due to creating many instances of business objects/loading much data - no large objects obviously), but actually didn't notice any positive or negative effects in the long term by doing so.
One more thing, triggering GC Collect explicitly may NOT improve your program's performance. It is quite possible to make it worse.
The .NET GC is well designed and tuned to be adaptive, which means it can adjust GC0/1/2 threshold according to the "habit" of your program memory usage. So, it will be adapted to your program after some time running. Once you invoke GC.Collect explicitly, the thresholds will be reset! And the .NET has to spent time to adapt to your program's "habit" again.
My suggestion is always trust .NET GC. Any memory problem surfaces, check ".NET Memory" performance counter and diagnose my own code.
Not sure if it is a best practice...
Suggestion: do not implement this or anything when unsure. Reevaluate when facts are known, then perform before/after performance tests to verify.
However, if you can reliably test your code to confirm that calling Collect() won't have a negative impact then go ahead...
IMHO, this is similar to saying "If you can prove that your program will never have any bugs in the future, then go ahead..."
In all seriousness, forcing the GC is useful for debugging/testing purposes. If you feel like you need to do it at any other times, then either you are mistaken, or your program has been built wrong. Either way, the solution is not forcing the GC...
There are some scenarios where there will definitely be very little to no negative impact on your system when forcing a garbage collection e.g. On a date roll/a scheduled time where the system is not in use.
Aside from such times you would need to test performance of your code before and after implementing the forced collect to ensure that it is actually beneficial.
I do NOT recommend manual garbage collection. I assure you that you're not disposing of large objects properly. Make use of the USING statement. Whenever you instantiate an object, be sure to DISPOSE of it when you are through using it. This sample code creates a connection with USING statements. Then it instantiates a shipping label object, uses it, and disposes of it properly.
Using con As SqlConnection = New SqlConnection(DB_CONNECTION_STRING)
con.Open()
Using command As SqlCommand = New SqlCommand(sqlStr, con)
Using reader As SqlDataReader = command.ExecuteReader()
While reader.Read()
code_here()
End While
End Using
End Using
End Using
Dim f1 As frmShippingLabel
f1 = New frmShippingLabel
f1.PrintLabel()
f1.Dispose()

Categories

Resources