It seems there may have been two regressions. The first regression with a
slowdown factor of just over 2 seems to be:
639621859863609c5f3abbc2ed75c675695b3693 is the first bad commit
commit 639621859863609c5f3abbc2ed75c675695b3693
Author: Jeff Bezanson <jeff.b{xxxxxx}@gmail.com>
Date: Tue Jan 26 23:33:19 2016 -0500
modify Base.Test not to create a closure for each test
:040000 040000 9c84c85afaed99190f3e744123dccc732f2c760e
486795536d95d1fb14fd9f7f415fb63cd9c6e490 M base
:040000 040000 48205a7b1b007692c81b1a8d931cb44f6cc97be8
acb43cd0ecece4237e1834b7a3b577f312884650 M test
I will try to find time to find the second regression, which occurs
between 1bfabbb and 1bfabbb I believe.
Bill.
On Wednesday, 23 March 2016 15:23:05 UTC+1, Bill Hart wrote:
>
> I'll see if it is possible. Currently our code does not work at all with
> large chunks of the Julia commits in that interval. We had to work around
> various things and don't know precisely when they were switched on or off.
>
> Bill.
>
> On Wednesday, 23 March 2016 14:54:22 UTC+1, Tim Holy wrote:
>>
>> If you can git-bisect the change, it would be a huge help.
>>
>> Best,
>> --Tim
>>
>> On Wednesday, March 23, 2016 06:18:23 AM 'Bill Hart' via julia-users
>> wrote:
>> > In very recent Julia-0.5-dev the test code in our Nemo module takes
>> forever
>> > to start running. It's close to 2 minutes.
>> >
>> > This compares with about 15s with older Julia-0.5-dev, say 3 months ago
>> > before the LLVM switchover.
>> >
>> > Does anyone know why there is this massive performance regression. Is
>> it
>> > likely that it can be fixed? It's really killing our development cycle.
>> >
>> > Bill.
>>
>>
