Dynamic symbol table

Lubos Lunak l.lunak at suse.cz
Fri Jul 16 12:52:49 CEST 2004


On Friday 16 of July 2004 12:40, Waldo Bastian wrote:
> On Friday 16 July 2004 12:09, Karl Vogel wrote:
> > Oh that's right.. strace can also trace through fork.. forgot about that.
> > Lol.. would probably have been more sensible to use strace than to hack
> > my kernel to log open() calls.. but it also worked :-)
> >
> > What I was trying to figure out, is whether loading of binaries is having
> > a negative effect on start time.
> >
> > One should be able to speed up the start time of binaries by putting the
> > initial startup code together, which means it will most likely be
> > together on disk also, which ultimately reduces I/O's.
> >
> > By (ab)using GCC's -fprofile-arcs & -fbranch-probabilities, it is
> > possible to put the start code in a different ELF section than the rest
> > of the code.
> >
> > The idea:
> > * add option to kde exe to directly stop after KApplication() setup
> > * compile exe with -O2 -fprofile-arcs
> > * start kde exe with the new stop option
> > * the profiled exe will dump stats to 'exename.da'
> > * compile exe with -O2 -fbranch-probabilities
> >
> > => gcc will now have put the startup code in section 'text.hot' and the
> > rest in 'text.unlikely'. So the startup code will be all together in the
> > exe, meaning less head seeking, less I/O & faster load. (and afterwards a
> > smaller RSS is needed to run the app)
>
> Yes, I once did some function reordering based on first usage and that
> showed indeed some improvement, but I didn't manage to find a convenient
> way to do that on a larger scale.
>
> Would be nice if someone could look into that. Just having a somewhat
> convenient to use tool to identify the hot code would already be a step
> forward.

 Note that ld.so in SUSE9.1 loads whole binary at once into memory instead of 
paging it in as needed, which reduces seeking (can be disabled by 
$LD_NOMADVISE). This was discussed here few months back. I'm not sure if this 
feature has made it into official glibc yet.

-- 
Lubos Lunak
KDE developer
---------------------------------------------------------------------
SuSE CR, s.r.o.  e-mail: l.lunak at suse.cz , l.lunak at kde.org
Drahobejlova 27  tel: +420 2 9654 2373
190 00 Praha 9   fax: +420 2 9654 2374
Czech Republic   http://www.suse.cz/


More information about the Kde-optimize mailing list