vibe.d 0.7.17 released

[Daniel Davidson]

On Tuesday, 10 September 2013 at 17:37:21 UTC, Dicebot wrote:

> I think I can safely answer this question in absence of Sonke 
> as someone subscribed to vibe.d commit log :)
>

Thanks

> It was asked and answered: 
> forum.rejectedsoftware.com/groups/rejectedsoftware.vibed/thread/1670 
> - not much has changed since then. Basically, almost all 
> popular benchmarks tends to focus on speed of utility modules, 
> not speed of HTTP server / application router itself. That is 
> something that has never been tested or put serious efforts 
> into.
>

In that thread Sonke said:

    "Agreed, I'd say we should start to prepare the benchmark 
cases and see how they actually compare against the others".

I can understand reservations about not wanting to publish 
benchmarks too early before some chance at optimization. OTOH, if 
it is "utility modules" that distort the numbers then maybe they 
need attention and data is the best way to draw it. And, just 
maybe, you and Sonke are too pessimistic? For example, shouldn't 
Json serialization be a win for D with its compile time approach?

> Area where vibe.d truly shines performance-wise is core request 
> handling framework and I am not aware of any public benchmark 
> game in that domain.
>

I bet you are correct. But then, how can you know if there is no 
public benchmark game in that domain  :-)

Maybe the best approach is to find a way to work more 
sophisticated tests into the benchmark that show where vibe/D 
shines. Without benchmarks it is all guesswork... but I'll bet 
the compile time diet templates shine. Other guesses?

> Now, if someone takes the time to run those tests manually and 
> tell how bad situation really is - that stuff would have been 
> really interesting to learn :)

Agreed!