On Thu, Jul 11, 2019 at 1:25 PM Sönke Ludwig via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

The problem is that for some reason it doesn't scale properly with the
number of cores in that benchmark. I have a dual-Xeon server that I can
in theory use for profiling this, but I simply still lack the time to do so.

Unfortunately that is not true anymore. Some time ago it was true, on my 4 core system vibed generaly has been one of the most fastest.

But now it is not true. So I am not sure the main issue is with number of cores.

If you or anyone else who is interested has a bit of time to spare, I
would suggest to change the benchmark setup to start one process per
core instead of using multiple threads. This is the preferred approach
anyway, for multiple reasons, but one of them being that it ensures
proper scaling, no matter if the GC kicks in, or some other kind of lock
contention happens.

I have already try this and there is no (countable) difference.

As I already said I have spent a lot of time to figure it out, but it seems the main issue right now is with vibe-d:http. But as Boris-Barboris mentioned maybe the main issue is with RC.