Study: build times for D programs

[Guillaume Chatelet]

On 07/24/12 16:34, Andrei Alexandrescu wrote:
> I was talking to Walter on how to define a good study of D's compilation
> speed. We figured that we clearly need a good baseline, otherwise
> numbers have little meaning.

I agree.

> One idea would be to take a real, non-trivial application, written in
> both D and another compiled language. We then can measure build times
> for both applications, and also measure the relative speeds of the
> generated executables.

Well I kind of did exactly that.

I was planning to start a Blog ("you know the blog you should really
really start but can't find time to do so") with such a comparison. I
started it a few months ago and can't finish the post so it's still
there, lying half finished. But as the subject pops out of the NG it
would be stupid not to talk about it.

I intended to add relevant numbers and go from deterministic measurable
facts to more subjective remarks ( was it fun ? is it more maintainable
? ) but I really just did a bit of the the first part :(

Anyway, so for people interested in my "findings" here is the half
finished post : http://goo.gl/16Yrb

This could serve as a basis of do's and don'ts for a more relevant
comparison as Andrei proposed. For instance it could be interesting to
compare the performance of several C++ and D compilers to get a measure
of the performance standard deviation expected within the language.

Also I think the D code could have been more idiomatic and optimized
further more : it was just a quick test ( yet quite time consuming ).

Both projects are opensource, one is endorsed by the company I'm working
for (https://github.com/mikrosimage/sequenceparser), the other one is
just a personal project for the purpose of the comparison (
https://github.com/gchatelet/d_sequence_parser )

By the way, it reminds me of the 'Computer Language Benchmarks Game'
(http://shootout.alioth.debian.org/). I know D is not welcome aboard but
couldn't we try do run the game for ourself so to have some more data ?

--
Guillaume