bad linking times [was Re: SUBMISSION: New Library for kdesupport: indexlib]

[Michael Pyne]

On Friday 10 June 2005 21:39, Michael Pyne wrote:
> So there is definitely an improvement, but it doesn't look like it would
> help all that much linking smoke (unless the change in question is one that
> e.g. changes an O(n^2) algorithm to O(n log n) and my n is too small to
> perceive the change).  But I don't want to delete libsmoke to find out. =D

OK, Maks reminded me that the gcc devs have complained about libtool leading 
to extravagant link times, so I wanted to see how much time I could save by 
skipping libtool and linking directly.

I wasn't sure how to munge unsermake's Makefile to change the link command 
line so I also skipped unsermake.  More on that later.

Anyways, the stats (performed in the same manner as my last test, let gcc run 
first to get it in cache, then record times).

ld 2.16           ld 2.16.90.0.3
--------          --------
6.561s            Not tested
6.687s

To figure out how much time unsermake was adding I ran unsermake in the build 
directory a few times as well:

unsermake
--------
0.652s
0.629s

So unsermake doesn't add a lot to the link times.  As a reminder, here were 
the times with unsermake + libtool + ld 2.16:

kde-toolchain (ld 2.16)
--------
11.92s
11.79s

This is scary guys.  It looks like fixing (or ditching) libtool would be a 
much easier way to speed up KDE compiles than to wait for updated versions of 
binutils.

Before I forget:  Yes, I actually tested the libtool-free executable, and it 
works just fine.

Regards,
 - Michael Pyne
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20050610/b7e238ad/attachment.sig>