'Standard' vapor website drops 1.5% of requests, even at concurrency of 100!

[axello (Axel Roest)]

@lukasa

It's worth pushing on this just a touch: whether Java runs the GC ends up being irrelevant. What matters is that allocating new objects in Java is approximately free, and it's delaying reclaiming them. Because BigInt objects in almost all languages are dynamically sized they require a lot of heap allocations, particularly if you create a lot and throw them away, as your benchmark does. Java (and Javascript!) both use a bump-allocator for these short-lived objects, and none of them are going to survive out of young-gen.

This is a really strong advantage in this benchmark. If you could get the BigInts allocated out of a bump allocator in the Swift code you'd likely see an immediate improvement in Swift's performance.

That explains the rapid memory growth of the java and javascript applications.

My --moral-- problem is: if I tweak the swift code to better handle memory allocations, the comparison seems less 'honest'. I could for example use the swap suggestion that @wadetregaskis proposes. But I should change the other code as well to even the odds, so to say.

OR, or: find a completely other benchmark
Or only calculate the floating point number and thus removing the need for the BigInt third party library.

Does anyone have an idea for a standalone benchmark technique, which does not involve databases etc. (Like TechEmpower does). Ideally where we can differentiate between the workload and the framework overhead?