On Thursday, 31 December 2015 at 08:23:26 UTC, Laeeth Isharc
wrote:
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.
vibe.d _was_ faster than Go. I redid the measurements recently
once I wrote an MQTT broker in Rust, and it was losing to
boost::asio, Rust's mio, Go, and Java. I told Soenke about it.
I know it's vibe.d and not my code because after I got the
disappointing results I wrote bindings from both boost::asio and
mio to my D code and the winner of the benchmarks shifted to the
D/mio combo (previously it was Rust - I figured the library was
the cause and not the language and I was right).
I'd've put up new benchmarks already, I'm only waiting so I can
show vibe.d in a good light.
Atila
