[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kfm-devel
Subject:    Re: FW: Bug#1812: KFM memory leak: updated patch for khtmlw.
From:       "Bjarni R. Einarsson" <bre () netverjar ! is>
Date:       1999-08-31 14:45:49
[Download RAW message or body]

Sorry if this doesn't thread correctly, I'm pasting from
http://www.lists.kde.org/, since I'm not actually subscribed to kfm-devel
(I'm just a power user, not a KDE developer). :-)

Waldo wrote:
> Would you care to tell what these numbers you mentioned mean? I guess
> it is some kind of memory usage. But of what? If it is the size of the 
> process you are just looking at noise.

The test results I'm referring to may be seen at:

    http://www.mmedia.is/~bre/programs/khtmlw.memleak.patch.txt

You are correct that I only measured the process size (using top) -
but if you read how I did it, you'll see that I took steps to minimize
noise - I used a fixed test sequence and logged out between each test
(necessary anyway to switch libs).  I normalized the size of all
windows, and had very few programs open (always the same ones).

Also I was measuring differences - not absolute sizes, I just
displayed the absolute sizes as well so people could verify my
calculations and do comparisons of their own.

I have added results that show how my patch does after Lars' fix has
been applied (patch.7) and how things turn out if only the memoryCache
is deleted (one line patch left as an excersize for the reader).

In short, I disagree with you about me seeing "noise".  I did my
homework, and the numbers I'm seeing reflect directly the changes I've
made to the code.  The only "weird" result was (unfortunately) the 
testing of patch.5 - but patch.7 is giving very stable, very nice
numbers to me.

My patches, and a description of the testing done with them may all
be found at http://www.mmedia.is/~bre/programs/.


> If the number of icons does increase wildly we need to find the cause
> of that instead of clearing the cache once in a while. This cache does
> what it is supposed to do. It might not be the best design to have an
> an ever increasing cache but 1.1.2 is not about redesigning.

Good code isn't just bug-free it should also be bug-tolerant.  My patch
makes this piece of code more bug-tolerant, in addition to fixing real
bugs (my other message explains this better, as does one of Lars').

And I still think my measurements speak for themselves.  If they're just
noise, please explain why the noise is so consistantly increasing the
memory usage, instead of displaying fluctuations such as can be seen
near the end of my test of patch.7.

-- 
Bjarni R. Einarsson                           PGP: 02764305, B7A3AB89
 bre@netverjar.is           -><-           http://www.mmedia.is/~bre/

                "I don't know man, I didn't do it."

[prev in list] [next in list] [prev in thread] [next in thread]