[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:       Waldo Bastian <bastian () suse ! de>
Date:       1999-08-31 15:16:13
[Download RAW message or body]

On Tue, 31 Aug 1999, Bjarni R. Einarsson wrote:
> 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.

Assuming that all leaks have been fixed in patch 7, the 'Leaked' column
shows the noise. 

You can see that it takes about 4 reloads to 'stabilize' the memory usage and
that you keep having fluctuations of about 50-100 bytes. 

So I think the difference between your measurments on the last two patches 
is quite clear.  But in the first set of measurments you can't tell whether the 
differences are noise or structural.

> 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').

Bug-tolerant code is really good but 4 days before a release is not the time 
to switch to bug-tolerant coding. So let's concentrate on real bugs. It is
obvious that there is a leak somewhere. The movie one-liner was one.
There must be another line like this somewhere in patch 7. 

The HTMLCache behaves very stange as well but it shuldn't be used during
your tests, so it can't be responsible for any of the leaks you see. Before we 
change  anything about it, I want to have a situation where you can clearly 
see that it is fucking up, and that after applying a patch it is behaving as 
expected.

> 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.

Your latest measurements give insight in the signal/noise ratio of your
measurements.

Cheers,
Waldo

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