[RESOLVED] Memory leak caused by drawing?

I'm observing a memory leak in my project and I do believe it is caused by the way I'm drawing.

My present usage was:

Code:

---

Private Sub MyPictureBox_Paint(ByVal sender As Object, ByVal e As System.Windows.forms.PaintEventArgs) Handles MyPictureBox.Paint
PictureBox_DoPaint(e.Graphics)
End Sub

Private Sub PictureBox_DoPaint(ByVal g As Graphics)
'some Paintings
Lines_DoPaint(g, MyPen, Lines)
End Sub

Private Sub Lines_DoPaint(ByVal g As Graphics, ByVal MyPen as Pen, ByVal Lines() as PointF )
g.DrawLine(MyPen,(g, MyPen, Lines)
End Sub

---

Using the Subs like that, the memory usage is steadily increasing.
When changing the Subs "PictureBox_DoPaint" and "Lines_DoPaint" the have only ByRef arguments, the memory usage seems to be steady.
Was this (one of) the reason(s) for my memory leak?

Quote:

---

Originally Posted by opus

I'm observing a memory leak in my project
[...]
Using the Subs like that, the memory usage is steadily increasing.

---

That's not necessarily a memory leak. Garbage Collection is expensive: if nothing needs the memory, why collect it? If you have unused RAM in your computer, then you paid for too much RAM.

:-(( above mentioned observing "seems to be steady", was correct only for some minutes. Now it is increasing even more.
@Evil_Giraffe: I'm worried because of the only increasing usage of memory (getting constant updates for 2K objects lets the applicatio have a rise of 30MB in 15 Minutes!)

My observing was that withouit drawing the objects (just recieving and processing them) the memory useage looked steady. That is the reason for looking into my drawing routines.

Quote:

---

Originally Posted by opus

@Evil_Giraffe: I'm worried because of the only increasing usage of memory (getting constant updates for 2K objects lets the applicatio have a rise of 30MB in 15 Minutes!)

---

Yes, but it doesn't mean there is a memory leak. If the system doesn't need to use those resources for something else, then freeing them is a waste of time, so it doesn't free them. It doesn't (necessarily) mean it is unable to free them.

That is all understood, however for the test I know what is snet to my application (exact 1920 objects, with changing kinematics) so the usage of memory should rise at the start, but it should come to a max level, which it doesn't.
I'm looking at the "Resource Monitor", the value for "Assured" (hopefully correct translated) Memory is riaing all the time.

You may know what is sent to your application, but you can't see what all those system calls may be doing. They will be creating objects internally to do their work.

What I'd expect to see in a "steady-state" application - if I may call it that: I just made that term up, but you kinda get what I mean, I hope? - is for memory usage to steadily increase up to a point, then drop down all of a sudden and continue rising steadily. This "saw-tooth" is Gen0 garbage collection kicking in. You might expect each "saw tooth" to not drop as much as it rises - this is because some objects may be in use when the GC kicks in, and get promoted to Generation 1. This is collected less frequently, but will still get collected if the system needs the resources. So eventually, you'll get a bigger drop when a Gen1 collection kicks in and get a sort of 'sawtooth-within-a-sawtooth". If an object in Gen1 is still alive when a Gen1 collection takes place, then they get promoted to Gen2 - which gets collected even less frequently than Gen1, so you'd actually expect a sawtooth-within-a-sawtooth-within-a-sawtooth. (There is no Gen3, so that's as far as the rabbit hole goes.)

This is all to be expected and is part of the normal memory management. Don't sweat it. You might want to leave your application running for a very long time or with a loaded system (or even better: both!) if you're concerned.

OK, I'm just upto such test.
I read about thet Gen0 and Gen1 procedure, what I didn't find is a (rough) estimate when the GC would try to collect. It is said that an explicit .Collect should not be used, but what timeframes are we talking about for an automatic .collect?

The test is running, this time on a much smaller system (in regards of RAM). What can be seen is, the "assured" memory and the "working..." memory are nearly equal. Both of them are constantly changing up and down, but NOT really increasing.
Evil_Giraffe your comment about "to much RAM" was really worth it. If there is too much RAM, the aplication will take more and more memory.

I was on a wrong way. ResMon.exe showed the GC Gen0 Objects are constantly increasing, but nothing is moved to Gen1 nor are they cleared when explicitly calling GC.collect.
Starting a new threat on that problem