This is the mail archive of the
glibc-bugs@sources.redhat.com
mailing list for the glibc project.
[Bug libc/250] perfomance of elf/do-lookup.h for c++
- From: "Woebbeking at web dot de" <sourceware-bugzilla at sources dot redhat dot com>
- To: glibc-bugs at sources dot redhat dot com
- Date: 4 Jul 2004 14:05:01 -0000
- Subject: [Bug libc/250] perfomance of elf/do-lookup.h for c++
- References: <20040701224041.250.Woebbeking@web.de>
- Reply-to: sourceware-bugzilla at sources dot redhat dot com
------- Additional Comments From Woebbeking at web dot de 2004-07-04 14:05 -------
(In reply to comment #2)
> You misunderstand what the patch you're referencing does. It speeds up
> string merging in SHF_MERGE sections, which has nothing to do with symbol
names.
The patch contains two speed improvements and I only refer to the use of
strrevcmp() (compare from right to left).
> Symbol names in ELF are zero terminated strings and their length is not
stored
> anywhere, so ld.so would either need to do strlen before comparing the
strings
This would be very slow indeed.
> backwards (note that for many symbols it is better to compare them from the
> beginning than from the end anyway), which would mean going through the
strings
This is right for i.e. C with short symbol names, but I'm talking about C++
where you have
_STL::_Rb_tree<QString, _STL::pair<QString const, Netzdat>,
_STL::_Select1st<_STL::pair<QString const, Netzdat> >, _STL::less<QString>,
_STL::allocator<_STL::pair<QString const, Netzdat> >
>::insert_unique(_STL::_Rb_tree_iterator<_STL::pair<QString const, Netzdat>,
_STL::_Nonconst_traits<_STL::pair<QString const, Netzdat> > >,
_STL::pair<QString const, Netzdat> const&)
or even longer ones.
> twice instead of once. That is certainly not faster. Or ld.so would need to
> cache the lengths somewhere, which complicates things a lot and I'm very
doubtful
> how much would it help.
Yes, you have to store the lenght somewhere (if a lib is loaded and the symbols
are "scanned" it shouldn't be too hard to call strlen() and store the length).
I think the use of strrevcmp() improved linking time of C++ by a factor of 2.
The complete patch improved it up to a factor of 10.
> It is better to avoid dynamic lookups, see prelink(8).
This is nice too, but you have to use prelink every time a lib was updated. A
speed improvement of ld.so would work every time.
Would be cool if someone could test if strrevcmp() would accelerate ld.so (once
more: probably only C++ apps will benefit from this- but if you think of KDE or
OpenOffice...).
André
--
http://sources.redhat.com/bugzilla/show_bug.cgi?id=250
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.