Change:
The build time of html5ever has gone up by more than 70% for debug builds recently: There are quite a few candidates for introducing this regression in the changeset: Would anybody from or care to bisect further?
The "tuple stress" benchmark is affected even more while most of the other things have improved. Maybe that gives a hint?
My first guess would be quadratic or exponential blowup. Maybe someone can do a ?
Yes, good idea!
Bisection for tuple-stress points to (cc Before that PR took ~4s and afterwards I killed it after 2m as I didn't want to wait for it to finish
That may also be the source of the html5ever regression. takes 10s before that commit (the entire time) and 21s afterwards.
Thanks, cc also &
Could you post instructions for replicating the slow down? Neither or I could reproduce it -- despite running perf on the appropriate commit range locally.
So should we revert that PR's commits?
sure yeah, using I did the equivalent of:
We should probably only run the disaggregation pass if the opt level is 1. That's what's done for the copy prop pass already
assuming and can reproduce I think yeah we'll probably want to start off by reverting and possibly doing what suggests in a follow-up
I cannot reproduce, which is odd, since I can't tell what the difference could be that would make this much of a difference...
No repro on macOS, although the c116 version is consistently slower than a272. <details</details
Ok I swear I'm not going crazy! I think though given this data it may only be reproducible on Ubuntu 16.04? I can reproduce with this : Can y'all reproduce the slowdown for html5ever?
Sure enough starting the docker image from 18.04 means I cannot reproduce the regression. Maybe some glibc bug was fixed which I was accidentally running into? The html5ever regression though is still worrisome and seems like it may not be connected to a glibc bug
I can repro the tuple-stress slow down on 16.04.4 LTS. indicates it is stuck at the step. <details<summaryGDB backtrace sample</summary</details<details<summaryCode surrounding the call of that memmove</summary</details
Presuming the same two commits would be responsible for the html5ever regression, I also cannot reproduce it on 18.04 Ubuntu.
Using this dockerfile: I can reproduce the regression from 10s to 20s on html5ever. Starting from 18.04 it does indeed not show a regression. The perf server is indeed 16.04. Ok so it looks like this is a regression specific to something that changed between glibc 2.23 and 2.27. With the profiles it looks like it's something related to the efficiency of memcpy/memmove. It also seems like this isn't reproducible on OSX (thanks ). I can, however, reproduce it locally on Windows 64-bit MSVC. Since could reproduce a slightly slowdown on OSX, I wonder if these code paths do something like exercise a ton of moves? It may be the case that glibc optimized one of its routines in the 2.23 -2.27 transition (and OSX already had it). In that case it may appear like there's no regression on Linux/OSX but on glibc 2.23 and Windows they may have unoptimized versions of the routines causing slowdowns. All in all I think that this is a regression that is still worth fixing, despite it not immediately being applicable on glibc 2.27 or OSX. The fact that it affects somewhat-recent versions of Ubuntu and Windows is enough for me.
Isn't glibc 2.27 the version released after the spectre/meltdown/whatever fixes that slow (primarily Intel but to a lesser extent AMD as well) systems down?
No sorry glibc 2.27 is just what I tested. I've now narrowed it down (conveniently) to glibc 2.23 and 2.24. Ubuntu 16.04 ships with 2.23 and 16.10 ships with 2.24. On 2.24 I'm seeing a faster compilation Perusing the it looks like may be why we're not seeing the regression in newer Linux
Ok I've found the source of the regression, will post a PR soon.
It's a pleasure watching you folks work!
I've posted what I believe is a fix to
triage: P-high Has pending fix.

Discussion:
// memmove back untouched tail, update to new length let start = source_vec.len(); let tail = self.tail_start; <del> let src = source_vec.as_ptr().offset(tail as isize); let dst = source_vec.as_mut_ptr().offset(start as isize); ptr::copy(src, dst, self.tail_len); </del> <ins> if tail != start { let src = source_vec.as_ptr().offset(tail as isize); let dst = source_vec.as_mut_ptr().offset(start as isize); ptr::copy(src, dst, self.tail_len); } </ins> source_vec.set_len(start + self.tail_len); } }