On 20.09.2011 2:27, Don wrote:
> On 17.09.2011 19:58, Peter Alexander wrote:
>> On 17/09/11 4:32 PM, Adam D. Ruppe wrote:
>>> Peter Alexander wrote:
>>>> In contrast, my D hobby project at only a few thousand lines of code
>>>> already takes 11s to build and doesn't do any fancy metaprogramming
>>>> or use CTFE.
>>>
>>> Curious, did you use a library like QtD?
>>
>> Nope.
>>
>> I use some parts of the standard library, not much of it though. I also
>> use Derelict, but again, not much of it.
>>
>> I'm talking about a -release -inline -O build btw.
>>
>> For a normal build it's only 1.7 seconds.
>
> I have a suspicion about what's causing this. The main loop of the
> optimiser has a O(n^^2) behaviour with consecutive comma expressions.
> -release -inline makes a large number of comma expressions (there
> doesn't need to be any in your code). I've seen n reach 200; maybe it
> gets even higher in your case.
> This isn't an intrinsic O(n^^2) algorithm, it would be pretty easy to
> fix, I think.
>
>

I have no solid facts to confirm this but I also noticed that combination of -O and -inline on my code does take few times longer to build then two builds with each of flags used separately.


-- 
Dmitry Olshansky

On Mon, 19 Sep 2011 18:27:29 -0400, Don <nospam@nospam.com> wrote:

> On 17.09.2011 19:58, Peter Alexander wrote:
>> On 17/09/11 4:32 PM, Adam D. Ruppe wrote:
>>> Peter Alexander wrote:
>>>> In contrast, my D hobby project at only a few thousand lines of code
>>>> already takes 11s to build and doesn't do any fancy metaprogramming
>>>> or use CTFE.
>>>
>>> Curious, did you use a library like QtD?
>>
>> Nope.
>>
>> I use some parts of the standard library, not much of it though. I also
>> use Derelict, but again, not much of it.
>>
>> I'm talking about a -release -inline -O build btw.
>>
>> For a normal build it's only 1.7 seconds.
>
> I have a suspicion about what's causing this. The main loop of the optimiser has a O(n^^2) behaviour with consecutive comma expressions. -release -inline makes a large number of comma expressions (there doesn't need to be any in your code). I've seen n reach 200; maybe it gets even higher in your case.
> This isn't an intrinsic O(n^^2) algorithm, it would be pretty easy to fix, I think.

While you're on speeding up compilation, here's another issue that causes dcollections unit tests to take 20 seconds to build, while building the release library takes less than a second:

http://d.puremagic.com/issues/show_bug.cgi?id=4900

This was after Walter fixed a really bad performance bug where symbols were searched linearly.  He says the same methodology (switch to hash table) should be used.

I'm hoping this speeds compilation up to the point where the main bottleneck is i/o.  Given how much percentage of compile time the linear searches take (at least in my case), this should bring down compile times significantly.  I think this one should speed up phobos builds too, because it's definitely exacerbated by lots of template instantiations.

-Steve

This thread is now on reddit:

http://www.reddit.com/r/programming/comments/kljc0/would_you_bet_100000000_on_d/