D perfomance

[Joseph Rushton Wakeling]

On Wednesday, 22 April 2020 at 14:00:10 UTC, serge wrote:
> 2) Various Web performance test on  
> https://www.techempower.com/benchmarks/#section=data-r18&hw=ph&test=query show pretty poor performance of D using vibe.d and hunt framework/libraries.  Regardless of type of test - json, single query, multiple query and so on.

I don't have a reference off the top of my head, but IIRC much of 
the upper end of those benchmarks is the result less of inherent 
language or framework differences and more to do with which 
implementations have been strongly tailored for each particular 
benchmark.  (I think this has been discussed on the D forums 
before.)

That tailoring to the benchmark often means dropping things (e.g. 
certain kinds of validation or safety measures) that any 
realistic app would have to do.  So the top end of those 
benchmark tables may be rather misleading when it comes to 
real-world usage.

There may well be framework design decisions in place that have a 
stronger impact.  For example I recall that the default 
"user-friendly" vibe.d tools for handling HTTP requests creates a 
situation where the easy thing to do is generate garbage per 
request.  So unless one addresses that, it will put ready 
constraints on exactly how performant one can get.

Note, this is _not_ a case of "the GC is bad" or "you can't get 
good performance with a GC".  It's a case of, if you use the GC 
naively, rather than having a good strategy for preallocation and 
re-use of resources, you will force the GC into having to do work 
that can be avoided.

So leaving aside misleading factors like extreme tailoring to the 
benchmark, I would suggest the memory allocation strategies in 
use are probably the first thing to look at in asking why those D 
implementations might be less performant could than they could be.

When it comes to the frameworks, the questions might be: (i) are 
there any cases where that framework _forces_ you into a 
suboptimal memory (re)allocation strategy? and (ii) even if there 
aren't, how easy/idiomatic is it to use a performance-oriented 
allocation strategy?