So, I know I’ve been silent for the past two days, and also today I won’t write too much. I’m still upset after the other night and sad for a goodbye I had to say even if I didn’t want to, which means that I’m in no mood for hard development (and I’m still without a system to work on Gentoo/FreeBSD).
Fortunately, Timothy is now taking care of some of the stuff I left behind, like keywording and some patching. And thanks to Alex now sandbox should be pretty fine on Gentoo/FreeBSD; I’ll be unmasking it as soon as I can test it firsthand (not base-profile-wide, but only for 6.2 profile).
Anyway, I was today considering, after about a week of usage of the new GNU hash style introduced with glibc 2.5 and binutils 2.17. The startup speed improvement is unnoticed, compared to the improvements of direct bindings (although they were all but safe).
The downside seems to be that when using the newest binutils, all the ELF files have 2MB of data added, which is very bad, because you end up trading a CPU-intensive task (the symbols’ binding) with the I/O intensive loading. I’m not sure why that happens, but it’s due to 2.17.50 versions of binutils. With the power poured in CPUs, I won’t accept this trade right now, as my I/O is all but lightspeed (still using SATA drives, and I have other tasks that are I/O intensive on their own). Consider that Konqueror links to 43 libraries, which means 86MB of hashes to load, KMail to 65, Amarok to 33 but you need to add the xine plugins, and all of this is with as-needed enabled, it gets worse if you don’t use it.
So, for the ricers out there, who are using the snapshot versions of binutils because they think they’ll get better performance… reconsider your thoughts, binutils 2.17.50.5 will decrease your performances, not improve them. I’ll try to see if the next releases fix this that seems to me like a bug, and reconsider hash style then.
