This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c/8108] Problem in the code generator for C and the linker is extremelly slow
- From: "stephan dot tobies at nokia dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 30 Mar 2004 07:46:56 -0000
- Subject: [Bug c/8108] Problem in the code generator for C and the linker is extremelly slow
- References: <20021001081602.8108.manuel.serrano@sophia.inria.fr>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Additional Comments From stephan dot tobies at nokia dot com 2004-03-30 07:46 -------
Subject: Re: Problem in the code generator for C and the linker
is extremelly slow
ext Manuel Serrano wrote:
>Hello Stephan,
>
>
>
>>I have also encountered this problem and, after spending some time profiling and
>>analyzing ld, have found what the problem is:
>>
>>It seems that ld uses a non-optimal algorithm to merge strings. This is done, if
>>I understand correctly, to be able to represent strings that are suffixes of
>>other strings as pointers into the longer string. Even though some hashing is
>>used in ld to reduce the search time, the employed algorithm has more or less
>>quadratic runtime in the number of strings.
>>
>>I assume that the placement of debug information has changed between older gcc
>>versions and newer gcc versions and that now the debug information is also mergable.
>>
>>This may lead to a dramatic increase in linking time when switching from older
>>versions to newer (3.2.2 for me) release. I have encountered a rise from ~10
>>seconds to ~1h.
>>
>>Suggestion: of course this should best be fixed in ld directly, and I will talk
>>to the guys there, but it would also help if gcc would receive an option that
>>makes it treat debug information as non-mergable data.
>>
>>
>I'm happy (well, not really), to see that I'm not the only one having this
>problem with gcc3. I have had the feeling that my problem was interesting
>exactly nobody. This is why I'm still using gcc2.95 :-(
>
>
No, when we start building large systems with lots of automatically
generated code, we run into this problem quite relyably, not only for
one system. Sticking with an old gcc is currecntly also the only option
for us :-(.
>The gcc3.2's option "-fno-merge-constants" gets rid of the problem.
>Unfortunately it has no effect with gcc3.3 (well, I have not tested recent
>versions, may be this has improved now).
>
>
Unfortunately, this is not really the case for us. We do not have that
many string constants in our code, so setting this option does not
change our linking times at all. What seems to be the killer for me is
the debug information. Currently there is no option to treat debug info
as non-mergable. I have already seen a gcc patch floating around that
achieves this, but I don't think that it is considered for inclusion
into the main gcc development, or even has been submitted.
There is a version of the binutils in the making (2.15) which will solve
the problem from the point of view of ld. They have a much improved
string merging algorithm that reduces link times for me from ~3000s to
~40s. This is still worse than the original ~7s (for gcc-2.95.x
generated objects) but it is 2 orders of magnitudes down.
BR
Stephan Tobies
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8108