Would You Bet $100,000,000 on D?

Steven Schveighoffer schveiguy at yahoo.com
Tue Sep 20 05:10:10 PDT 2011


On Mon, 19 Sep 2011 18:27:29 -0400, Don <nospam at 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


More information about the Digitalmars-d mailing list