Simple web server benchmark - vibe.d is slower than node.js and Go?

[Sönke Ludwig]

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)