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

BigInt.+ isn't doing anything particularly expensive. It has cost that's linear in the size of its input, and for values beyond 2^128 it includes an allocation to hold its result. I'd expect it to be generally in the ballpark of other big integer implementations.

(It doesn't do anything special, though -- it includes no clever SIMD tricks: it boils down to a boring loop of addingReportingOverflows.)

Given that this benchmark is quite deliberately using big integer additions as a way to generate load, I'm not surprised that it would dominate the performance analysis.

How confident are we that BigInt.+ is actually meaningfully slower than, say, Java's BigInteger.+? There may be an unexpected stdlib regression lurking there.

swift-numerics is our official home for numerics solutions outside the stdlib. It has a feature branch for BigInt development; it has been in the works for over four years now.

5 Likes