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!
