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