Scott L. Burson wrote:
> Thanks for looking at this, Ali.
>
> I certainly can upgrade to GCC 4.3. I suspect, however, from what you say,
> that this will just get me back to the performance of the snv_86 linker,
> which was already poor. (I don't mean specifically snv_86; that's just the
> version I happen to be using; AFAIK the performance hadn't changed since
> Solaris 10, until this linkonce stuff was added sometime after snv_86.)
>
> So it might be interesting if you could also dig up an older linker and try
> that too. Meanwhile I will get started on the GCC upgrade.
>
> BTW, what did you use to profile this? If DTrace, could you post the script?
> (Just curious)
>
> -- Scott
Well, getting back to the performance of the snv_86 linker would
be a worthwhile improvement, right? :-)
(Only a partial joke --- I have to believe that it would help reduce
the pain until a better answer can be developed).
There are some separate issues here:
1) Big slowdown with introduction of linkonce processing
2) Performance of ld vs gld before the big slowdown
3) Unknown performance of ld group processing when facing
super large C++ objects.
Now, we don't build C++ programs of the size you're pushing, and
we had not heard these complaints, so for us, the game is just starting.
We have a good test case that will let us work on 1 & 2. If you
find 3 to be a problem also, then we'll take another set of objects
from you and look into that too... :-)
I used olde tech to profile it:
% LD_PROFILE=libld.so.4 LD_PROFILE_OUTPUT=. sh ld-command
% gprof -b /lib/amd64/libld.so.4 libld.so.4.profilex > report
This was an easy first thing to try, since all I was looking for was
a broad sense of where the time is going.
- Ali
