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: 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 :)


Reply via email to