[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 12:54:56
[Download RAW message or body]

On Tue, 31 Aug 1999, Bjarni R. Einarsson wrote:
> On Tue, Aug 31, 1999 at 11:44:58AM +0100, David Faure wrote:
> > Some more on the subject.
> > 
> > A main khtmlw developer (Waldo) told me this about the cache :
> > 
> > > > > The cache in khtmlw is for icons only. It is intended that this cache
> > > > > is never deleted/cleared. A normal web-page does not load any
> > > > > icons and does not use this cache at all.
> 
> This may be true - but if you look at the patch test results
> you'll see that my first patch, which didn't address the
> movieCache problem at all, did improve memory usage measurably,
> with no noticable performance impact.
> 
> IMHO that justifies it. :-)

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.

> Any buffer that can grow indefinately, without ever being
> deleted/cleared is IMHO a misfeature.  If they feel I'm too
> aggressive they should just grow the PCACHESIZE to a larger
> number which they feel is more appropriate - then if the number
> of icons really *does* increase wildly my patch will kick in and
> do it's thing, without interfering with normal operation.

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
ever increasing cache but 1.1.2 is not about redesigning.

> But really, the patch isn't all that big, and it should be
> trivial to verify that it isn't doing anything bad - especially
> for people familiar with the code.

It is as trivial as preventing any of these bugs in the first place.
 
Cheers,
Waldo

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