My alternative “concept” browser

As I keep spitting fire on current browsers as you can read through my last posts since all of them are real resource hogs consuming memory and resources like crazy, I announced the possibility of creating my own concept browser, meaning that I will base it’s core on an existing one (embedded) and just implement my concept of how a real browser should handle resources.

My first project went up in smoke using TEmbeddedWb (from bsalsa) which is based on IE because with every tab switch the memory grew with around 3-5 MB. Then I tried some others, based on gecko but I ran into other problems PLUS memory leaks (although smaller).

So I got back to TEmbeddedWB because I got an idea: why not also destroy the object instance? This should force a complete memory de-allocation. Partially true.

Then I did some research and found the following:

// force memory to be really de-allocated: http://www.bsalsa.com/forum/showpost.php?p=2551&postcount=19
SetProcessWorkingSetSize(GetCurrentProcess, $FFFFFFFF, $FFFFFFFF);
{FROM MSDN: -1, -1: If both dwMinimumWorkingSetSize and dwMaximumWorkingSetSize have the value (SIZE_T)–1, the function removes as many pages as possible from the working set of the specified process.}
// also equivalent to EmptyWorkingSet

Which indeed now showed a very nice grow of “only” 1 MB per tab BUT, this time depending on the contents of the tab. So if you load a 10 mb tab and then a 1 MB tab, or load a 10 MB and then a 20 mb, you still only loose 2 MB instead of 6+

So I figured if this really dropped the memory usage for the IE based project, how about trying the gecko one, despite the other bad “habits” it has. After fiddling with it a bit I got it working and the test results showed a pretty similar pattern in “leaking” as the one with IE. So at least from leaking point of view, the gecko and IE based projects are similar.

As a weird side-note, (I’m on D7 here and now) even after enabling the OleCtrls memory leak fix and recompiling EWB the memory leaks remained the same. True, that I didn’t use any interface property references which would explain this, but I thought that internally, the component might use them. Oh well, nothing is lost but nothing is gain either.

Since the mozilla activex control that I use for the gecko implementation is a bit old and unmaintained and lacks a lot of needed features for a browser, I will go with TEmbeddedWB in implementing a very skeletical and bare-bone and minimalistic but very light and resource friendly tabbed-browser.

And maybe I can finish it before the end of the year 🙂

Related posts

Tags:

Leave a Reply

This blog is kept spam free by WP-SpamFree.