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