vibe.d 0.7.17 released
nospam at spam.com
Tue Sep 10 11:10:39 PDT 2013
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 :)
> It was asked and answered:
> - 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
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 :)
More information about the Digitalmars-d-announce