Not sure why you are getting downvoted here. Your question is very valid.
As far as the Techempower results go, I'm pretty sure it is not a GC issue. It could be the postgres implementation issue. Someone has to work with upstream to tune and fix the issues.
Contributing to such benchmarks require time and effort. A small community can do only so much in their free time.
Even though such benchmarks are good marketing, the D community is not interested in participating such benchmarks (although I'm quoting one post from the D forum, the trend is same).
It's not D which us performing poorly here, it's vibed.
Rather look at the benchmark game if you want to compare numbers. Older versions, which did include the better languages
> how could it be changed to get better performance?
Mostly, pay attention and profile to get better performance.
---
For example, if you look at rust, you see that the top(actix) and the middle frameworks have some big distance. The former autor of actix care to get good result, others are just in the step of "have something working nicely"
That's a little disingenuous. h2o isn't really a framework as much as it is a server that can be extended as an application (Similar to CherryPy vs Flask/Django). There aren't really any good C web frameworks, and any web applications built in C are very likely to be bespoke code utilizing some HTTP library (libhttp, h2o, kore, etc).
Actix is a framework, built in Rust and non-GC'd, that performs significantly better than any of the Go frameworks. So GC does seem to have some effect.
That being said, I agree the GC is unlikely to be the problem for D's performance (in this case).
It's not all clear that a garbage collector isn't an advantage in actual workloads. Web apps tend to create a lot of short lived objects, and contrary to popular assumption malloc and free are not free.
The alternative of gc is not malloc and free. It's custom memory management, i.e. the code that decides when to execute malloc and when to execute free. Even a gc will ultimately call the equivalent of malloc or free. The difference is gc needs to do it generic enough that it works for all possible programs; whereas a programmer needs to do it in a way it works for this particular program.
https://www.techempower.com/benchmarks/
I was expecting Rust or C level of performance for D. Instead, D performs on the same level as Ruby and Python.