On Wednesday, 30 December 2015 at 20:32:08 UTC, yawniek wrote:
Sönke is already on it.
http://forum.rejectedsoftware.com/groups/rejectedsoftware.vibed/post/29110
i guess its not enough, there are still things that make vibe.d
slow.
i quickly tried
https://github.com/nanoant/WebFrameworkBenchmark.git
which is really a very simple benchmark but it shows about the
general overhead.
single core results against go-fasthttp with GOMAXPROCS=1 and
vibe distribution disabled on a c4.2xlarge ec2 instance
(archlinux):
vibe.d 0.7.23 with ldc
Requests/sec: 52102.06
vibe.d 0.7.26 with dmd
Requests/sec: 44438.47
vibe.d 0.7.26 with ldc
Requests/sec: 53996.62
go-fasthttp:
Requests/sec: 152573.32
go:
Requests/sec: 62310.04
its sad.
i am aware that go-fasthttp is a very simplistic, stripped down
webserver and vibe is almost a full blown framework. still it
should be D and vibe.d's USP to be faster than the fastest in
the world and not limping around at the end of the charts.
Isn't there a decent chance the bottleneck is vibe.d's JSON
implementation rather than the framework as such ? We know from
Atila's MQTT project that vibe.D can be significantly faster than
Go, and we also know that its JSON implementation isn't that
fast. Replacing with FastJSON might be interesting. Sadly I
don't have time to do that myself.
