Dynamic symbol table

[Frans Englich]

On Thursday 15 July 2004 21:55, Karl Vogel wrote:
> Frans Englich wrote:
> > On Thursday 15 July 2004 21:09, Karl Vogel wrote:
> >> Karl Vogel wrote:
> >> > I noticed that a lot of the .so files have big dynamic symbol tables,
> >> > as if everything is exported. Wouldn't it be better to only export the
> >> > symbols that are really required?!
> >>
> >> Seems like it is indeed not needed. I've changed the Makefile.am of
> >> some kcm modules to use a version script which only exports init_*
> >> and create_* symbols.
> >
> > A quick note: A half year ago a macro for factory declaration of KControl
> > modules was proposed(to be declared in kcmodule.h), but postponed for KDE
> > 4. If this optimization turns out useful, it could perhaps be part of
> > such a declaration macro(I can look up the patch, if of interest).
>
> I noticed that some modules used K_EXPORT_COMPONENT_FACTORY. As I first
> only had the create_* function exported, but the newer modules using the
> factory, export init_*
>
> ie. kdelibs/kdecore/klibloader.h
>
> #define K_EXPORT_COMPONENT_FACTORY( libname, factory ) \
>     extern "C" { void *init_##libname() { return new factory; } }
>
> But there is nothing to restrict the export of the other symbols yet... but
> maybe it was already on the KDE4 to-do list?!
>
>
> Anyway I'm interested in reducing startup time.. and this seemed like a
> good starting point...
>
> Has anybody done some detailed analysis yet as to where most time is wasted
> at startup?! Sprinkling 'date' commands in my startkde script shows that
> ksmserver is where I loose the most time... but that encompasses alot..  so
> time to dig into the ksmserver source (and related commands that are
> started by ksmserver)


Optimizing KDE startup has been pondered many times before -- check the 
archive, it got much to tell.

(Disclaimer: I have no idea what I'm talking about)

Regarding modules, one way I thought of startup optimization was to make 
kcminit threaded in order to keep IO busy and do useful stuff while syscalls 
sleeps. Many of these init kcms deals with hardware and they may sleep for 
long times in their sycalls. For example, I once measured how long the kmix 
kcm took to initialize on my (broken) setup: 5 seconds(hot cache). Anyway, 
threading could be an idea. To avoid IO trashing the code could sleep small 
amounts of time between the spawning of threads(an average determined by 
testing different setups, or calculated in some intelligent way).
Could anyone who actually knows about this stuff deny/"write a 
patch"/elaborate? :)

AFAIK, most of the init kcms only contains a couple of LOCs -- the code path 
takes nothing compared to the loading of the library. This can be easily 
helped by doing init for several "areas" in one init function(there are cases 
where this can be done without breaking modularization; randr and xinerama, 
for example). For KDE 4, perhaps.


			Frans