bad linking times [was Re: SUBMISSION: New Library for kdesupport: indexlib]
pynm0001 at comcast.net
Sat Jun 11 03:30:20 BST 2005
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 188.8.131.52.3
6.561s Not tested
To figure out how much time unsermake was adding I ran unsermake in the build
directory a few times as well:
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)
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
Before I forget: Yes, I actually tested the libtool-free executable, and it
works just fine.
- Michael Pyne
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the kde-core-devel