vibe.d benchmarks

[Etienne Cimon via Digitalmars-d]

On Thursday, 31 December 2015 at 08:51:31 UTC, yawniek wrote:
> On Thursday, 31 December 2015 at 08:23:26 UTC, Laeeth Isharc 
> wrote:
>> 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.
>
> this is not the same benchmark discussed elsewhere, this one is 
> a simple echo thing.
> no json. it just states that there is some overhead around on 
> various layers.
> so its testimony is very limited.
>
> from a slightly more distant view you can thus argue that 50k 
> rps vs 150k rps basically just means that the framework will 
> most probably not be your bottle neck.
> none the less, getting ahead in the benchmarks would help to 
> attract people who are then pleasantly surprised how easy it is 
> to make full blown services with vibe.
>
> the libasync problem seem seems to be because of TCP_NODELAY 
> not being deactivated for local connection.

That would be the other way around. TCP_NODELAY is not enabled in 
the local connection, which makes a ~20-30ms difference per 
request on keep-alive connections and is the bottleneck in this 
case. Enabling it makes the library competitive in these 
benchmarks.