Why is vibe.d still performing bad in benchmarks?

[Boris-Barboris]

On Thursday, 11 July 2019 at 09:50:52 UTC, Daniel Kozak wrote:
> This is what I am trying to do for some time now (few months), 
> but vibe.d
> code is not so easy to read and debug. So far I have found out 
> that
> vibe-core seems to not be the main problem (there are still some
> potentional speed improvment), but it seems the issue is 
> somewhere in
> vibe-d:http.
> There is some work on new version of this package (
> https://github.com/vibe-d/vibe-http) , so maybe the performance 
> of this new
> attempt will be better. I am goint to try this new vibe-http, 
> but I am not
> sure if it is already in usable state.

I remember finding vibe-core's reference-counting facility, aka 
InterfaceProxy, very taxing on the upper layers. There is a lot 
of passing a round and the lack of move semantics makes each 
function call that involves some kind of stream or managed 
reference an excercise in integer mutation. In pure http 
throughput tests it was very noticeable, around 10-30% drop in 
rps.

Eventcore is another arcane library very deep on the stack, I 
don't think anyone ever profiled it in isolation (correct me if 
I'm wrong), yet it's the heart of the event loop.

On the topic itself, well, the answer is always the same: 
everything's in it's right place.
In the usual hierarchy of merits:

productivity > correctness > flexibility and domain coverage > 
performance

vibe-d stack is still wrestling with the first three components, 
and rightfully so.