This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug c/8108] Problem in the code generator for C and the linker is extremelly slow


------- 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]