GNU Binutils 2.41 release

[Tsukasa OI]

On 2023/08/05 9:38, Sam James via Binutils wrote:
> 
> ASSI <Stromeko@nexgo.de> writes:
> 
>> Nick Clifton via Binutils writes:
>>> We are pleased to announce that version 2.41 of the GNU Binutils project
>>> sources have been released and are now available for download at:
>> […]
>>
>> I see massive performance degradation in ld on Cygwin when linking
>> libraries or executables with a large number of objects.
>>
>> For example compiling protobuf-21.12:
>>
>> binutils-2.39: 1420.820u 143.747s  3:20.37 780.8%      0+0k 0+0io 41531073pf+0w
>> binutils-2.40: 1429.088u 140.548s  3:18.48 790.8%      0+0k 0+0io 41615637pf+0w
>> binutils-2.41: 1496.555u 524.457s 10:07.31 332.7%      0+0k 0+0io 41570112pf+0w
>>
>> The linking step alone:
>>
>> binutils-2.39:   14.212u   2.614s  0:20.54 81.8%       0+0k 0+0io 1909884pf+0w
>> binutils-2.40:   13.371u   0.839s  0:20.46 69.4%       0+0k 0+0io 1910885pf+0w
>> binutils-2.41:   85.507u 373.960s  7:55.39 96.6%       0+0k 0+0io 1905021pf+0w
>>
>> I have another much larger application where the linking went from
>> seconds to over an hour.
>>
>> The fact that a lot of that extra time is spent in system might provide
>> a clue for finding the culprit.  BUt there's extra time in user as well
>> and it seems to scale superlinearly with the number of objects.  It's
>> possible that objdump performance has also suffered, I've not yet
>> checked this in detail.
>>
> 
> Please file a bug with the details so we can discuss it there and
> collect some reproducers.
> 
>>
>> Regards,
>> Achim.
> 

As well as the issue reported by ASSI, I found similar report (possibly
a linker performance regression with Cygwin) in X (formerly Twitter).  I
asked him to detail the issue and he kindly provided me a report (though
in Japanese).  At least I'll try some gprof-based profiling.

<https://fd0.hatenablog.jp/entry/2023/08/05/220135>

Tsukasa