llvm dev - Aug 2014 - [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

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>

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.