I’ve done few benchmarks, and I’m seeing a significant performance difference. (It’s approaching the performance of the CPython numbers, so for casual purposes it now seems fast enough. But I don’t know if there are some corner cases where bigint is much slower).
The small-int optimization (allowing it to store a usize and isize without heap allocations) is handy for such library because it makes it more flexible. You can use such small-int-opimized bigints as replacement for regular ints when performance of the code is not maximally important, but you need the code to work correctly (and to not panic and crash in case of moderate overflows). Several languages work like this, their integers are not fixnums, like Python and even Common Lisp (https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node17.html ). If bigint gains the small-int optimization then it should also gain attributes like the most-positive-fixnum and most-negative-fixnum of CommonLisp.
So you can think of such bigints with small-int optimization like another behaviour beside the panic, wrapping and saturating ones.
I like the Whiley language (http://whiley.org/ ), a language focused on provably correct code. It uses multi-precision integers, because they act more like the ideal integers from mathematics, allowing simpler proof of correctness of the code. Rust could someday prove similar properties on its code with the help of something like Z3 (https://github.com/Z3Prover/z3 ) when the code uses the bigints (that should be efficient enough for normal code that doesn’t need to use huge integers).
Perhaps currently there’s no way to create library-defined small-int-opimized bigints that are as polysemous as the built-in integral numbers. Solving this problem should help such big-ints become more flexible and better drop-in replacements for built-in integral numbers. I don’t know how this can be done…
(Beside being polysemous, in future I’d like Rust built-in integral numbers (and library numbers) to have another property inspired by D language, but this is better left to a separated future post).