[Bug libc/250] perfomance of elf/do-lookup.h for c++

["Woebbeking at web dot de" <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.