search for: 209801

...ells. The reason I pointed this patch out is that the pattern in which performance changes matches precisely the pattern this patch was applied and reverted, with the set of patches between subsequent performance runs being rather small. Note, this patch is actually the smaller culprit, around 209801 there is another performance regression, but I have no idea if/where this is coming from or if this for some reason is a false positive. I unfortunately currently don't have the time to investigate this, but thought I at least mention it on the mailing list. Cheers, Tobias P.S: Until the...

On 1 August 2014 21:33, Chandler Carruth <chandlerc at google.com> wrote: >> Note, this patch is actually the smaller culprit, around 209801 there is >> another performance regression, but I have no idea if/where this is coming >> from or if this for some reason is a false positive. > > > I'm having to question the results on this bot. The range of commits which > cause the larger compile time regression is 2...

Hi, I was just browsing my LNT performance builder and it seems within the last month we managed to increase compile time from 37 to 47 seconds for the bullet benchmark: http://llvm.org/perf/db_default/v4/nts/graph?plot.0=34.274.3&highlight_run=29054 A similar pattern can be seen for MallocBench/gs/gs where we go from 5.3 to 7.4 seconds.