[Bug ld/30724] Massive ld performance regression in binutils-2.41 since 014a602b86f08de96fc80ef3f96a87db6cccad56
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 in binutils-2.41 since 014a602b86f08de96fc80ef3f96a87db6cccad56
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
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
https://sourceware.org/bugzilla/show_bug.cgi?id=30724 --- Comment #4 from Achim --- As I suspected, the newlib fseek/fseeko implementation flushes the file under lock (because it punts to fseek_r/fseeko_r) when in append mode and also for SEEK_CUR before determining the current position (as it has no way of knowing if it was changed by something else). An fflush forces the next read to go to system as mandated by POSIX. There is read optimization when having an absolute position (SEEK_SET) and the stream is read-only. So removing the optimisation for (not) seeking an unchanged file position is not a no-op at least for newlib targets. -- You are receiving this mail because: You are on the CC list for the bug.