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

List:       kfm-devel
Subject:    Re: Zone allocator (KHTML)
From:       Waldo Bastian <bastian () ens ! ascom ! ch>
Date:       1999-06-07 15:16:39
[Download RAW message or body]

David Faure wrote:
> 
> I think libkonq would benefit a lot from using it.
> It has to create a lot of instances of KFileIcon
> (one per file, that can go to very high numbers !)
> and destroy them all at once, when going to another dir
> (I guess that a "coupled lifecycle"...)

Yes. Exactly.

> Currently konqueror and kdesktop have classes that _inherit_
> from KFileIcon (in order to add UI functionality)
> but I want to change this : I'm currently writing
> KDirLister that will create simple KFileIcons.
> 
> It seems KDirLister could easily and efficiently use the Zone Allocator
> to allocate KFileIcons, couldn't it ?

How efficient it will be depends a bit on the number and size of 
the objects. 
How easy it is depends on:
* Is KDirLister the only class allocating KFileIcons? 
* Have you access to all places where KDirLister calls "new KFileIcon(..)"?

If the answer is yes in both cases, you can overload operator new() in
KFileIcon just as I did in KHTML (the code is still in the unicode-branch)
operator delete() should be overloaded as well with a dummy function.

You can no give each KDirLister its own Allocator and instead of calling
"new KFileIcon(..)" you call "new(Allocator) KFileIcon(..)"

After destructing all KFileIcons you can destruct the allocator to return
the memory.

> In the UI classes (konq_iconview, konq_treeview, kdesktop),
> there will have to be other objects created for each file
> (KonqKfmIconViewItem, KDesktopIcon [which I'll merge]
>  and KonqKfmTreeViewItem).
> They won't inherit from KFileIcon anymore.
> Should I use the zone allocator for them as well ?
> They comply to 'coupled lifecycle' but not to 'same class'.
> 
> Thanks for your advice.

If they have a coupled life cycle you can use the zone allocator 
to allocate them, and then the memory can get returned in one big
go, when they all have been destroyed. 

The easiest way to do this is to overload operator new and delete 
for the objects. This, in its turn, is most easily done by inheriting
from a common class. Either because the hierarchy is already like this
or because you force the inheritance with double inheritance.

If they don't have a coupled life cycle but have  a alot of objects 
which are all of the same size you can apply a slightly different 
allocator which maintains a free list and which can return pages
when whole pages gets freed. 

I will put the allocator itself in kdecore as well as a simple object
which overloads operator new/delete. You should then be able to use
it by just inheriting this object.

Cheers,
Waldo

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