Am 21.09.2017 um 10:01 schrieb Vadim Lopatin:
There is a simple set of simple web server apps written in several
languages (Go, Rust, Scala, Node-js):
https://github.com/nuald/simple-web-benchmark
I've sent PR to include D benchmark (vibe.d).
I was hoping it could show performance at least not worse than other
languages.
But it appears to be slower than Go and even Node.js
Are there any tips to achieve better performance in this test?
Under windows, I can get vibe.d configured to use libevent to show
results comparable with Go. With other configurations, it works two
times slower.
Under linux, vibe.d shows 45K requests/seconds, and Go - 50K. The only
advantage of D here is CPU load - 90% vs 120% in Go.
I'm using DMD. Probably, ldc could speed up it a bit.
Probably, it's caused by single threaded async implementation while
other languages are using parallel handling of requests?
Multi-threading (or multi-process processing) is probably the main
reason. The following initialization code should get this on par:
shared static this()
{
runWorkerTaskDist({
listenHTTP("0.0.0.0:3000", &handleRequest);
});
}
The other part is that currently the HTTP server code works rather
inefficiently with the new vibe-core implementation, ironically due to
the main feature that is meant to speed up vibe-core over the previous
implementation: using statically typed structs instead of dynamic
interfaces for streams. This currently requires using proxy objects in
the HTTP server, which perform their own type of dynamic dispatch, with
a higher overhead than using classes/interfaces directly.
But there is a pending redesign of the whole HTTP implementation, which
will, among other things, get rid of this and will use statically typed
streams throughout the code. It should then be considerably faster than
the current code path that uses classes/interfaces.
Finally, there is also a considerable performance bug in vibe-core
currently, which I can't fix due to an unresolved Optlink bug:
https://github.com/vibe-d/vibe-core/pull/27 (I tried to reduce this with
dustmite, took about a week, but of course it reduced to a piece of code
that was actually broken - I'll have to redo this with using the MS
linker in parallel as a counter test)
