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

List:       kfm-devel
Subject:    Re: Zone allocator (KHTML)
From:       David Faure <david.faure () insa-lyon ! fr>
Date:       1999-06-03 8:35:34
[Download RAW message or body]

On Wed, Jun 02, 1999 at 11:49:14AM +0200, Waldo Bastian wrote:
> Hiya,
> 
> I'm proud to announce the succcesfull deployment of a Zone allocator
> in KHTML. The Zone allocator allows to allocate all objects used for
> building up a HTML-page in several large (128Kb) blocks of memory.
> The blocks of memory are freed when the HTML-page is destructed,
> not when the indivual objects get destructed.
> 
> The advantages are:
> *) No overhead from malloc/new. This saves about 10% for large pages.
> *) The blocks are (at least under Linux 2.2.x) returned to the OS
> when the page is destructed. This is unfortunately not the case with
> traditional memory allocation.
> 
> I'm considering to move some support classes for this to kdecore if
> there are more applications who could benefit from this. My question
> is: 
>      Do you know/have an application which uses large amounts of 
>      objects (e.g. 1000) which have a strongly coupled lifecycle?
> 
> These applications might benefit from a Zone allocator. (A newsreader
> perhaps?)
> 
> I am also interested to learn about applications that use a large
> number of objects of the _same_ class without necesarrily a strongly
> coupled lifecycle.

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

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 ?

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.

-- 
David FAURE
david.faure@insa-lyon.fr, faure@kde.org
http://www.insa-lyon.fr/People/AEDI/dfaure/index.html 
KDE, Making The Future of Computing Available Today

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