4 ms·

One thing I saw in KDE applications (KDE has split its base libraries into a bazillion small libraries) is that looking up a symbol in a dynamic library is fast

One thing I saw in KDE applications (KDE has split its base libraries into a bazillion small libraries) is that looking up a symbol in a dynamic library is fast, but linearly trying all the libraries is costly - (IIRC) 20-40% of startup time. A possible solution would be to store with each symbol where it's expected to come from. Required libraries are listed as an array, so the "where" could be an index into the array. Symbol overriding would have priority over that lookup mechanism, but apart from overrides, lookup could be just one hash lookup in the already known library. I am still hoping for someone else to implement that so I occasionally mention the idea :)

Findecanor 5y ago
> A possible solution would be to store with each symbol where it's expected to come from. Solaris extended their ELF format with "Direct Binding" in 2005. It messes with intentional interposition though. (<https://blogs.oracle.com/solaris/post/direct-binding-now-the-default-for-osnet-components https://blogs.oracle.com/solaris/post/direct-binding-now-the...>) Michael Meeks did an implementation of Direct Binding for GNU binutils and glibc but it got rejected to be in the mainline with "prelink is more efficient". (<https://lwn.net/Articles/192082/ https://lwn.net/Articles/192082/>) I haven't found anything about the Direct Binding in GNU that is more recent than 2006. Maybe time to revisit?