so i came across this little gem of a thread on the bin utils list from last october. in it, openoffice hacker michael meeks provide a fairly extensive patch that improves start up times dramatically for c++ apps that rely on dlopening libraries. what kind of apps might benefit from that? well, openoffice and pretty much every kde app for starters. and how much of an improvement does this patch provide? it achieves somewhere around twice the current performance. yes, that means that many apps would start up twice as quickly (though not all, of course; there are other things that can wreck start up time ;)
we have a nicer fontconfig start up profile, lots of optimizations happening in the desktop applications and libs and it's all helping; wouldn't it be nice to see this patch in the next glibc and binutils releases? well, keep dreaming for the time being because ulrich drepper, the maintainer of this package, apparently doesn't understand the patch and is letting it bit-rot. rather disappointing to see such an improvement that would help so many projects in a real-world manner get blocked due to one person acting as a (blocked) bottleneck in the process.
apparently some distros are going to be rolling out binutils/glibc's with at least parts of meek's patches, but that's hardly the best way to go. here's to hoping someone wakes up and gets this contribution pushed into upstream so everyone can enjoy the benefits of it, including users of red hat linux who happens to employ drepper.
Subscribe to:
Post Comments (Atom)
8 comments:
Hi Aaron
Thanks for bringing this up - I'm a gentoo dev running those patches and the speedup is really decent. I haven't recompiled my whole system as it would be needed, but a lot of it, and it is nice. And it's not just dlopening libraries - every program benefits from it as the dynamic-symbol resolution process gets the speedup. So anything from a simple ls (if not compiled with --as-needed... ^^) up to a full-blown kde benefits. Bdirect improves starting a program, but has the benefit of actually coming into effect when dlopening as well.
The patches aren't without issues though, but comparing to the ugly solution with prelink, bdirect really shines.
There were further discussions with speedups Meeks provided on the binutils mailinglist (hashvals comes into my mind). I wouldn't just give up on this, but I am still happy that you brought this up on your blog
Thanks
Benjamin Schindler
well, then, let me voice some support for this, too. i guess Drepper has good reasons for rejecting the patch, but i hope he and Meeks can fix 'em and get this in.
> i guess Drepper has good reasons
> for rejecting the patch,
if he does, he's keeping them to himself. it really seems he's just letting it slip through the cracks without thinking about it very hard.
Yes, it would be nice to at least get a reason why this patch was rejected like it is complete sh*t.
This is not some useless eye-candy or something, it makes the whole system go faster (I also used it locally). Why would something that benefits *every* apps get rejected so fast? NIH syndrome? Pride? Why?
This is really interesting, thanks for posting this Aaron. I'm just curious... how is OO's startup time in Linux compared to let's say FreeBSD. They use their own C library right? Would be nice to know the startup time on Solaris, because the coder of these patches said he was inspired from Solaris. I can't test this, because i'm only running Linux.
Hmmm. Although Drepper's response was, erm, rather short there were reasons behind it. You can actually achieve what Michael was doing with Bdirect by using a hacked prelink, and arguably, better. Unfortunately, Bdirect breaks things in the same way as a hacked prelink would do which is to do with the way ELF libraries are supposed to work - and probably why the patch was rejected. If you want to know about this stuff I'd talk to Lubos about it:
http://www.kdedevelopers.org/node/1650#comment-4090
and more importantly:
http://www.kdedevelopers.org/node/1661
In summary, it looks as though it wouldn't make much of a negligible change to KDE, and there are some issues to be worked around whatever methid is used. It makes a big difference for Open Office because it is so badly designed.
@segendum: yes, i'm aware the patch as was posted isn't perfect, but it does improve things and could itself be improved. there's a good reason it will (at least in part) be in upcoming SUSE releases, for instance.
> Bdirect breaks things in the same
> way as a hacked prelink
not quite; it breaks things for similar reasons but with different consequences.
> as though it wouldn't make much
> of a negligible change to KDE
decreasing start up time by 5-7% (which is, i understand the general effect for KDE) is a nice win when you get it "for free". in terms of optimizing, every 5% win in a situation like this is generally regarded as important.
for start up times this is doubly so since people notice those delays to a sub-second granularity.
there's a good reason it will (at least in part) be in upcoming SUSE releases, for instance.
Hmmm. A slight fork? I'm not sure about that.
decreasing start up time by 5-7% (which is, i understand the general effect for KDE) is a nice win when you get it "for free".
Agree there. Every small bit you can add to make into a whole is a win.
However, the patch was mainly submitted because of Open Office, and it is going to make very little difference to that app. Whether it is run on Windows or a Linux system it is extremely slow to start up whatever you do. Bigger wins could be gained in other areas, but for KDE I suppose it is another small win amongst many that all add up.
Post a Comment