Re: [Dillo-dev][RFC] Limiting the size of Cache

[Pekka L. <me...@ka...>]

Hi,

On Wed, 20 Feb 2002 15:22:58 -0300
Livio Baldini Soares <li...@im...> wrote:

>   I have started writing a patch that adds a `cache_size' to Dillo's
> options, because currently the cache has no limit, therefore,
> everything you download gets cached into memory. I've made a very
> premature patch, which has a few know bugs...

I too looked to this issue, and even wrote little patch. Though never
got it ready to send here. My patch has little different approach.


>   But what I want to know is, is this a wanted feature? Now that I've
> made Dicache optional, does anyone still see Dillo hogging up RAM?
> Before the Dicache removal, I could get 40MiB of use from Dillo after
> a fews hours of browsing. But now the _maximum_ I've hit is 20MiB.

I think this is definately needed. 20 megs can be just too much for old
systems. And if you have fast connection (local proxy maybe), and not
too slow machine, there is no reason to waste the memory. :)

>   The problem with making this patch, is that it'll eventually be an
> overhead, especially for low cache_sizes... Maybe I'll have to try
> harder to make a "low/no-overhead" solution.

I haven't had time to test your patch (only read it through). But I
don't think it will make too much overhead.

My implementation is based on counting the references on cache entrys.
So it has separate mode for totally disabling cache (always removes
cache entry when no references left). This should limit the need to use
very small cache sizes. And even with small cache size profiling looked
very good.

Another feature which could also be implemented without need to refcount
(I think). Is prioritising the removal of cache entrys by their sizes.
Don't know if this is usefull or not.

Your patch is much more cleaner and smaller than mine. I never even
though of doing this some other way than refcounting. Don't know what
style should be used for final implementation.

I'll try to clean up my patch tomorrow and post it here.

-- 
Pekka Lampila
me...@ka...