Tobias Grosser
2014-Aug-01 20:05 UTC
[LLVMdev] Recent compile time performance regressions
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. http://llvm.org/perf/db_default/v4/nts/graph?plot.0=34.301.3&highlight_run=29054 One contributing patch seems to be the following one (surprisingly): Author: Chandler Carruth <chandlerc at gmail.com> Date: Fri Jun 27 15:13:01 2014 +0000 Re-apply r211287: Remove support for LLVM runtime multi-threading. I'll fix the problems in libclang and other projects in ways that don't require <mutex> until we sort out the cygwin situation. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk at 211900 I also looked at the earlier performance regressions, but could not find any obvious commits that could have caused these regressions. This is mostly a drive by observation, but maybe someone is motivated to investigate this further. Cheers, Tobias
Chandler Carruth
2014-Aug-01 20:07 UTC
[LLVMdev] Recent compile time performance regressions
Note that I've fixed one bad compile time regression quite recently, and we're bisecting to another one. We benchmarked the multithreading stuff pretty carefully, so I doubt its that. Have you tried reverting locally and reproducing? On Fri, Aug 1, 2014 at 1:05 PM, Tobias Grosser <tobias at grosser.es> wrote:> 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. > > http://llvm.org/perf/db_default/v4/nts/graph?plot.0> 34.301.3&highlight_run=29054 > > One contributing patch seems to be the following one (surprisingly): > > Author: Chandler Carruth <chandlerc at gmail.com> > Date: Fri Jun 27 15:13:01 2014 +0000 > > Re-apply r211287: Remove support for LLVM runtime multi-threading. > > I'll fix the problems in libclang and other projects in ways that > don't require <mutex> until we sort out the cygwin situation. > > git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk at 211900 > > I also looked at the earlier performance regressions, but could not find > any obvious commits that could have caused these regressions. > > This is mostly a drive by observation, but maybe someone is motivated to > investigate this further. > > Cheers, > Tobias >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140801/0fbfb901/attachment.html>
Tobias Grosser
2014-Aug-01 20:16 UTC
[LLVMdev] Recent compile time performance regressions
On 01/08/2014 22:07, Chandler Carruth wrote:> Note that I've fixed one bad compile time regression quite recently, and > we're bisecting to another one. We benchmarked the multithreading stuff > pretty carefully, so I doubt its that. Have you tried reverting locally and > reproducing?Not really. It just saw this passing by and was wondering if it raised some bells. 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 last performance build at juli 31st the performance regression still existed, so I don't think your fix applied to this one.