KDE 4 namespaces

David Faure faure at kde.org
Mon May 9 13:35:54 BST 2005


On Monday 09 May 2005 14:11, Thiago Macieira wrote:
> David Faure wrote:
> >On Monday 09 May 2005 13:27, Thiago Macieira wrote:
> >> In the case of KIO, I'd like to see the ioslave-related classes moved
> >> to another library. There's no need for SlaveBase, TCPSlaveBase &
> >> family to be in applications.
> >
> >(Not sure what "family" is, I think there's only both SlaveBase classes)
> 
> Read: the other ioslave-specific classes.

I know, but which are those? I don't think there are any more than those two.
If I can use nm correctly, those two classes export 121 symbols.
libkio is about 8137 symbols in total...

> >Given that kioslaves and apps are all forked by kdeinit, isn't faster to
> >have *SlaveBase in kio, rather than opening a new lib for every forked
> > slave?
> 
> Maybe. But, then again, is it worth the performance decrease? If it's a 
> small library, the impact won't be great, while we gain in size for 
> applications.

Do we? Given that we fork apps from kdeinit, I don't see what we "gain in size"?

What we gain for apps we lose for slaves. Since one konqueror process can easily
spawn 5 http slaves for a webpage, this would tend to indicate that saving on 
slave startup time is pretty important too.

> Another possibility is for kdeinit to open that library as well. Maybe we 
> could improve kdeinit by having a "ioslave-like" instance open, with less 
> libraries (namely, libkdeui and libkonq). The effect would be smaller 
> memory size.
...at the expense of one more daemon process...
Optimization is difficult; what you gain somewhere you lose somewhere else.

Also, note that KIO requires kdeui (for many things), and slaves require kio
(for KMimeType, UDS stuff, etc.), so you can't remove kdeui from the list of 
dependencies for a kioslave.

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).




More information about the kde-core-devel mailing list