How do I release RAM from my windows forms app by deleting the history cache of webbrowser controls?

Question

0.00/5 (No votes)

See more:

I want it to use less of the system's RAM.

What I have tried:

webbrowser1.Dispose();
webbrowser1 = null;

And the RAM is still used by the program (seeing that in Task Manager it doesn't get lower).

Posted 7-Jan-19 16:46pm

john1990_1

Updated 7-Jan-19 23:23pm

v3

Add a Solution

Comments

OriginalGriff 8-Jan-19 1:53am

Link removed: unless you want to be treated as a spammer (and banned from the site) don't let me see that link again...
This time, I think it was over exuberance, but twice will be spamming.

john1990_1 8-Jan-19 1:55am

Ok, sorry.

OriginalGriff 8-Jan-19 3:16am

No problem - just be glad it wasn't one of our more trigger-happy members that spotted it! :laugh:

1 solution

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

OriginalGriff · Answer 1 · 2019-01-07T20:01:00

Solution 1

Memory allocated in your app comes from a pool called the Heap: this does not go down in size when you release memory in your app, and it not automatically released back to the operating system.

Calling Dispose does not necessarily release memory back to the heap: that is only done by the GarbageCollector and that only kicks in when the heap is getting full.

You can't "see" your apps real usage of memory in Task manager: that shows the framework use of memory. To see what your heaps (plural, because there are more than one heap) is doing, you need to use a profiling tool, such as WinDbg, or the VS profiller: Diagnosing memory issues with the new Memory Usage Tool in Visual Studio – Microsoft DevOps Blog[^]

Posted 7-Jan-19 20:01pm

OriginalGriff

Comments

john1990_1 8-Jan-19 2:04am

Thanks, this is so complicated, any simple way to sum it up to add lines of code to my program?

OriginalGriff 8-Jan-19 3:19am

No, it's not a "lines of code" type problem. You're trying to monitor *how* your app works, you don't do that from inside the app as that changes the way it does things.
A bit like trying to time marathon runners by strapping grandfather clocks to each of them: it works, but it changes the speed they run at!

john1990_1 8-Jan-19 3:27am

I understand from you that when the heap is getting full the garbage collector kicks in and releases the cache of webbrowser controls (after webbrowser1.Dispose() has been called), and I don't need to worry about my users' RAM getting full?

OriginalGriff 8-Jan-19 3:49am

It's complicated ...

The GC kicks in and starts cleaning house, releasing memory that is no longer referenced, but it does that when it wants - basically when it can't allocate a big enough chunk of memory you asked for - although you can "ask it nicely" to run when you want, it really isn't needed.

The complications come when you realise that there are multiple heaps: three Generation Heaps, and a Large Object Heap (the later is not compacted ... unless you tell it to in V4.5.1 and later) ... unless .NET is operating in Server mode in which case it allocates separate heaps to each logical processor so the GC operations can be done in parallel ...

https://docs.microsoft.com/en-us/dotnet/standard/garbage-collection/large-object-heap

Basically, unless you really need to know just ignore memory and assume the system will take care of it! :laugh:
It's fascinating stuff (if you like that kind of thing, and I do) but in general you don't need to worry about it.

There is also the added complication that "memory" isn't just the space you store stuff in, Windows also considers Handles as "memory" and it's very possible (even easy) to run out of Handles long before you start approaching the memory limits of your machine. When you do, you get an "Out of memory" error despite the GC and / or actual memory allocation not being involved at all! That's why it's important to "tidy up" after yourself with any Graphics objects such as Fonts, Brushes, Pens, ... and to remember that each Window requires a Handle, and that each Control is at least one window, sometimes many, many more. Disposing of handles is very important!

Dave Kreskowiak 8-Jan-19 10:00am

Task Manager is showing how much memory is RESERVED for your app, not how much it's actually using.

When your app launches, the .NET CLR asks Windows for a block of memory. The block becomes the managed heap for your application. As your application runs and allocates objects, the CLR allocates memory to them out the managed heap. Some of the heap is used, some of it isn't, but it's ready to be used by your application.

If the CLR is running low on available heap, it'll ask Windows for another block and add it to the managed heap.

If Windows is running low, it'll ask the .NET to return memory back to it. The CLR will happily remove memory from it's managed heap and return it back to Windows.

If you want to see how much memory your app is actually using, you have to use PerfMon and the .NET Memory counters.