std.d.lexer performance (WAS: std.d.lexer : voting thread)

[Jonathan M Davis]

On Friday, October 11, 2013 12:56:14 Dmitry Olshansky wrote:
> 04-Oct-2013 15:28, Brian Schott пишет:
> > On Thursday, 3 October 2013 at 20:11:02 UTC, Andrei Alexandrescu wrote:
> >> I see we're considerably behind dmd. If improving performance would
> >> come at the price of changing the API, it may be sensible to hold off
> >> adoption for a bit.
> >> 
> >> Andrei
> > 
> > The old benchmarks measured total program run time. I ran a new set of
> > benchmarks, placing stopwatch calls around just the lexing code to
> > bypass any slowness caused by druntime startup. I also made a similar
> > modification to DMD.
> > 
> > Here's the result:
> > 
> > https://raw.github.com/Hackerpilot/hackerpilot.github.com/master/experimen
> > tal/std_lexer/images/times5.png
> > 
> > 
> > I suspect that I've made an error in the benchmarking due to how much
> > faster std.d.lexer is than DMD now, so I've uploaded what I have to
> > Github.
> > 
> > https://github.com/Hackerpilot/lexerbenchmark
> 
> I'm suspicious of:
> printf("%s\t%f\n", srcname, (total / 200.0) / (1000 * 100));
> 
> Plus I think clock_gettime often has too coarse resolution (I'd use
> gettimeofday as more reliable).
> Also check core\time.d  TickDuration.currSystemTick as it uses
> CLOCK_MONOTONIC on *nix. You should do the same to make timings meaningful.

Why not just use use std.datetime's benchmark or StopWatch? Though looking at 
lexerbenchmark.d it looks like he's using StopWatch rather than clock_gettime 
directly, and there are no printfs, so I don't know what code you're referring 
to here. From the looks of it though, he's basically reimplemented 
std.datetime.benchmark in benchmarklexer.d and probably should have just used 
benchmark instead.

- Jonathan M Davis