tuning ld performance
Andy Chittenden
achittenden@bluearc.com
Mon Jan 26 16:21:00 GMT 2004
I've managed to get the executable relinking now and 2.14.90.0.8 is quicker
than 2.14.90.0.7. _bfd_strip_section_from_output is still out there as the
biggest CPU hog:
2.14.90.0.8 unchanged:
# time y
real 2m56.954s
user 1m20.300s
sys 0m11.949s
2.14.90.0.8 with my _bfd_strip_section_from_output hack (ie return before
the loop):
# time y
make
real 2m7.302s
user 0m34.950s
sys 0m11.923s
The user time has come down from around 46 seconds to around 35 seconds
between 2.14.90.0.7 and 2.14.90.0.8. Fantastic: CPU saving of around 25% -
still would like to get this down further though. The percentage time in
bfd_hash_lookup has gone up and is now @ nearly 77%:
Flat profile:
Each sample counts as 0.01 seconds.
% cumulative self self total
time seconds seconds calls s/call s/call name
76.94 218.13 218.13 5046492 0.00 0.00 bfd_hash_lookup
11.42 250.50 32.37 1687 0.02 0.11
_bfd_link_section_stabs
1.42 254.53 4.03 22100 0.00 0.00 walk_wild_section
1.16 257.81 3.28 1700 0.00 0.01 ldlang_add_file
1.10 260.93 3.12 628133 0.00 0.00 get_special_section
We're now becoming I/O bound as well as the real amount of time seems to be
constant no matter how many times you run it. So although improving CPU time
would be beneficial, I suspect the next thing to tackle is I/O.
--
Andy
*********************************************************************
This e-mail and any attachment is confidential. It may only be read, copied and used by the intended recipient(s). If you are not the intended recipient(s), you may not copy, use, distribute, forward, store or disclose this e-mail or any attachment. If you are not the intended recipient(s) or have otherwise received this e-mail in error, you should destroy it and any attachment and notify the sender by reply e-mail or send a message to sysadmin@bluearc.com
*********************************************************************
More information about the Binutils
mailing list