Nice. Is the speed-up primarily from avoiding big.Int's SetString method? If so, would it be worth fixing upstream instead (or in addition)?

Is the speed-up primarily from avoiding big.Int's SetString method? If so, would it be worth fixing upstream instead (or in addition)?

Right. Beyond the reduced complexity of strconv.ParseInt compared to (*BigInt).SetString thanks to the fixed bit size, the main win here is the avoidance of a heap-allocated strings.Reader. I don't see a good way to avoid this in the standard library, given the different callers to (*BigInt).setFromScanner. At least not until the standard library adopts generics, and even then I don't recall whether the new GC shape stenciling will be enough to avoid heap allocations in cases like these. Do you happen to know?

I don't see a good way to avoid this in the standard library, given the different callers to (*BigInt).setFromScanner.

I had in mind putting it at the beginning of (*Int).SetString, not (*Int).setFromScanner, here:

https://cs.opensource.google/go/go/+/refs/tags/go1.18.3:src/math/big/int.go;l=425

(Given where we are in the Go release cycle, it'd be worth doing here as well.)