Leon Bottou: Faster KDE Startups?

As a follow-up to Waldo Bastian's analysis of KDE startup times, Leon Bottou has implemented an inspired hack to improve the startup of C++ programs under GNU/Intel systems. "Waldo Bastian's document demonstrates that the current g++ implementation generates lots of expensive
run-time relocations. This translates into the slow startup of large C++
applications (KDE, StarOffice, etc.). The attached program "objprelink.c" is designed to reduce the problem. Expect startup times 30-50% faster." Update: 08/01 4:52 AM by N: Consult Leon's objprelink page for some great details and up-to-date information on this hack as well as on the prelinker mentioned by Bero. Thanks to freekde for the tip-off.

If I understand correctly, Leon's hack works around the problem by adding a level of indirection - a stub - to each function in a class's virtual table, and changing references to the function to point to the new stub instead -- thereby eliminating a whole lot of symbol lookups and relocations.

Check out Leon's email for the exact juicy details and for the Intel/GCC-specific C code of the program you will need to process object files before linking. One possible downside of this optimization is that virtual function invocations may now be slower due to the extra indirection involved.

And of course, no matter how brilliant the hack, we are still working around faults in the GNU linker. Apparently some work is going on in that area as well as can be seen in this email from Jakub Jelinek.

Dot Categories: 

Comments

by Rik Hemsley (not verified)

You're right, I could make a new style plugin. I had
forgotten that I could change the plugin used by
a 'themed style' by altering the .themerc file.

I _would_ recommend dropping out inlined methods
wherever you can. Only keep them in for code which
is on a critical path. If you fill your headers with code,
no-one can override that code later.

Optimisation rule #1: Don't. Not until you've measured.

Rik

by Mosfet (not verified)

If you do what your recommending you have apps (that may or may not be in a critical loop, how are you to know as a library developer?), in absurd situations like being in loops making method calls for things like "a=b;" and "++i;". This is insane and may be acceptable to you, but certainly isn't to me and judging by it's use not acceptable to others as well. This is exactly why people use inline.

Also, you can't rely on the compiler optimizing small methods inline automatically like you would if a C function did the same thing.

by Joe Zbiciak (not verified)

One thing to keep in mind is that each relocation also results in a dirty page. If the relocations are spread throughout the application, then you're going to generate a lot of page faults very quickly, and make many trips into and out of the kernel. If any of these pages would be sharable, they get COW'd (Copy on Write). Ouch.

A secondary benefit of prelinking is that apps which use the same libraries are more likely to share pages. This reduces system memory footprint and regains one of the key advantages of shared libraries.

by me (not verified)

Anybody has a solution for the "no space for .dynamic" error???