A Very Slow Link-Edit - get the latest patch
| A Very Slow Link-Edit - get the latest patch | |
Rod Evans — Thursday October 13, 2005
A customer recently posted to the Dynamic Linking forum in regards to an awfully slow link-edit. A shared library, built from Sun Studio 10 with debugging (-g), was taking 20 minutes to link on Solaris. By comparison, the same link took 4-5 minutes on Linux, and 15 seconds on Windows.
I got a copy of the objects and found that the link-edit was considerably faster on my desktop - less than a minute. This is no small link-edit. There are a number of very large input files, and in total, ld(1) processes 65057 input symbols, and the killer, over 1.3 million input relocations.
It turns out we'd already uncovered a scalability issue from investigating a slow link-edit from another customer. Basically there are some tests within ld(1) that attempt to identify displacement relocation use within data items that have the potential for copy-relocations. Not something typically users come across, but an area where our compiler engineers had once fallen foul. Thus the checks were requested by our compiler developers to aid their experimentation.
A patch already existed that addressed this slow link-edit, which was fixed
under bugid 6262789. The patches are:
Solaris/SunOS 5.10_sparc patch 117461-03
Solaris/SunOS 5.10_x86 patch 118345-03
Solaris/SunOS 5.9_sparc patch 112963-21
Solaris/SunOS 5.9_x86 patch 113986-17
Solaris/SunOS 5.8_sparc patch 109147-36
Solaris/SunOS 5.8_x86 patch 109148-36
The customer now has the relevant patch. Their link-time is down to 35 seconds.Which is still not as fast as Windows, so we still have some work to do. Perhaps the compilers could generate a little less for us to do :-).
| [18] Init and Fini | [20] Runtime Token Expansion |