On Tuesday, 10 September 2013 at 18:10:40 UTC, Daniel Davidson wrote:
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?

Well, we don't know. Now one has been ever benchmarking this. Ever. Someone needs to step up and provide the data. I will do it eventually, but that will happen later rather than sooner.

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

I've done some testing on my own ;) https://github.com/Dicebot/web-performance-tests - unfortunately, I was not able to get meaningful results for high concurrency cases because of h/w limits generic crappy laptop network cards have (should probably delete existing ones as they are mostly useless), but it provides all the tools for one to try and see :P

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?

There is always an option to create your own benchmarking game :P All you need is production-grade networking hardware and pair of PC's (with client being considerably more powerful than server).

Reply via email to