mpz_t caching

Vincent Lefevre vincent at
Mon Sep 7 10:54:11 UTC 2015

On 2015-09-07 12:36:51 +0200, Niels Möller wrote:
> Vincent Lefevre <vincent at> writes:
> > I suspect that the cause
> > of the difference is that with mpz_t caching, the mpz_t's are
> > preallocated with a size that is large enough to avoid internal
> > reallocations in GMP (thus memory copies), but in such a case, the
> > right solution would be to use mpz_init2.
> The lazy initialization discussed a few days ago might also help a bit,
> then limb storage isn't allocated until the first assignment to the
> variable, and then reallocations should be less likely.

Doesn't this save only the first allocation? Like mpz_init, I don't
think that this should be visible. The only possible cause I'm
thinking of, would be a succession of reallocations in a loop
because the mpz_t's are growing.

Vincent Lefèvre <vincent at> - Web: <>
100% accessible validated (X)HTML - Blog: <>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

More information about the gmp-devel mailing list