[Bug ld/30724] Massive ld performance regression in binutils-2.41 since 014a602b86f08de96fc80ef3f96a87db6cccad56

2023-08-05 Thread Stromeko at nexgo dot de
https://sourceware.org/bugzilla/show_bug.cgi?id=30724

--- Comment #3 from Achim  ---
(In reply to Andrew Pinski from comment #2)
> That would be then a bug in cygwin stdio code I suspect ...

Maybe, or maybe it actually has to be that way since the wording in POSIX seems
to imply that when certain open modes are in effect, then an fseek requires
flushing or the equivalent thereof (when the mode changes, which Cygwin may not
be able to detect reliably, so it may have to assume the mode will change).

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug ld/30724] Massive ld performance regression in binutils-2.41 since 014a602b86f08de96fc80ef3f96a87db6cccad56

2023-08-05 Thread pinskia at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=30724

--- Comment #2 from Andrew Pinski  ---
(In reply to Achim from comment #1)
> AFter a few false starts since it seems one really needs to freshly
> configure and compile the whole thing each time this got bisected to:
> 
> https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;
> h=014a602b86f08de96fc80ef3f96a87db6cccad56
> 
> Why and how this produces the effect I've reported is a massive
> head-scratcher, but I've confirmed that with this patch reverted 2.41 does
> not only link as fast as 2.40 again, it is actually faster:
> 
> 2.41re:   10.494u   1.370s  0:17.01 69.7%   0+0k 0+0io 1904230pf+0w

That would be then a bug in cygwin stdio code I suspect ...

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug ld/30724] Massive ld performance regression in binutils-2.41 since 014a602b86f08de96fc80ef3f96a87db6cccad56

2023-08-05 Thread sam at gentoo dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=30724

Sam James  changed:

   What|Removed |Added

Summary|massive ld performance  |Massive ld performance
   |regression  |regression in binutils-2.41
   ||since
   ||014a602b86f08de96fc80ef3f96
   ||a87db6cccad56
 CC||amodra at gmail dot com

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug ld/30724] massive ld performance regression

2023-08-05 Thread Stromeko at nexgo dot de
https://sourceware.org/bugzilla/show_bug.cgi?id=30724

--- Comment #1 from Achim  ---
AFter a few false starts since it seems one really needs to freshly configure
and compile the whole thing each time this got bisected to:

https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=014a602b86f08de96fc80ef3f96a87db6cccad56

Why and how this produces the effect I've reported is a massive head-scratcher,
but I've confirmed that with this patch reverted 2.41 does not only link as
fast as 2.40 again, it is actually faster:

2.41re: 10.494u   1.370s  0:17.01 69.7%   0+0k 0+0io 1904230pf+0w

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug ld/30724] massive ld performance regression

2023-08-05 Thread pinskia at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=30724

Andrew Pinski  changed:

   What|Removed |Added

 Target||cygwin
 CC||pinskia at gcc dot gnu.org
   Severity|critical|normal

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug ld/30724] massive ld performance regression

2023-08-05 Thread sam at gentoo dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=30724

Sam James  changed:

   What|Removed |Added

 CC||sam at gentoo dot org

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug binutils/30725] severe objdump performance regression

2023-08-05 Thread sam at gentoo dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=30725

Sam James  changed:

   What|Removed |Added

 CC||sam at gentoo dot org

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug binutils/30725] severe objdump performance regression

2023-08-05 Thread ssbssa at sourceware dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=30725

Hannes Domani  changed:

   What|Removed |Added

 CC||ssbssa at sourceware dot org

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug ld/30724] massive ld performance regression

2023-08-05 Thread ssbssa at sourceware dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=30724

Hannes Domani  changed:

   What|Removed |Added

 CC||ssbssa at sourceware dot org

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug binutils/30725] New: severe objdump performance regression

2023-08-05 Thread Stromeko at nexgo dot de
https://sourceware.org/bugzilla/show_bug.cgi?id=30725

Bug ID: 30725
   Summary: severe objdump performance regression
   Product: binutils
   Version: 2.41
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: binutils
  Assignee: unassigned at sourceware dot org
  Reporter: Stromeko at nexgo dot de
  Target Milestone: ---

On Cygwin the performance of objdump has further degraded with 2.41.  The
extraction of the debuginfo source files from the objects with "objdump -d -l"
that was already quite slow sees an additional 2× slowdown cs. the previous
version.

* cygport gcc install

2.39:  8763.607u 284.933s   29:14.38 515.7%   0+0k 0+0io 41005478pf+0w
2.40: 10122.687u 249.745s   31:29.71 548.8%   0+0k 0+0io 41382419pf+0w
2.41: 23065.196u 516.525s 1:02:40.22 627.1%   0+0k 0+0io 41348709pf+0w

The timing of install phase of gcc is dominated by the objdump invocation and
there mainly by the compiler executables (d21 usually takes the longest).

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug ld/30724] New: massive ld performance regression

2023-08-05 Thread Stromeko at nexgo dot de
https://sourceware.org/bugzilla/show_bug.cgi?id=30724

Bug ID: 30724
   Summary: massive ld performance regression
   Product: binutils
   Version: 2.41
Status: UNCONFIRMED
  Severity: critical
  Priority: P2
 Component: ld
  Assignee: unassigned at sourceware dot org
  Reporter: Stromeko at nexgo dot de
  Target Milestone: ---

On Cygwin there is a massive performance regression during the link phase with
version 2.41.  The degradation is superlinear in the number of objects involved
and I have observed link operations that take more than 30× longer than with
the previous version.

One of the changes suspected was 38395c77, but that doesn't seem to be the main
contributor to the regression (at least not in isolation).

* cygport protobuf-21.12 compile

2.39: 1420.820u 143.747s  3:20.37 780.8%  0+0k 0+0io 41531073pf+0w
2.40: 1429.088u 140.548s  3:18.48 790.8%  0+0k 0+0io 41615637pf+0w
2.41: 1496.555u 524.457s 10:07.31 332.7%  0+0k 0+0io 41570112pf+0w

* only the linking of protobuf-21.12

2.39:   14.212u   2.614s  0:20.54 81.8%   0+0k 0+0io 1909884pf+0w
2.40:   13.371u   0.839s  0:20.46 69.4%   0+0k 0+0io 1910885pf+0w
2.41:   85.507u 373.960s  7:55.39 96.6%   0+0k 0+0io 1905021pf+0w
38395c77/pdb.c w/o call to qsort
84.933u 363.715s  7:37.01 98.1%   0+0k 0+0io 1906464pf+0w
38395c77/pdb.c full revert
82.964u 361.461s  7:30.39 98.6%   0+0k 0+0io 1906266pf+0w

-- 
You are receiving this mail because:
You are on the CC list for the bug.