mpz_t caching
Niels Möller
nisse at lysator.liu.se
Mon Sep 7 16:54:04 UTC 2015
Vincent Lefevre <vincent at vinc17.net> writes:
>> 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?
You're right. I was thinking that the application used some 300 bits for
most values, and then there would be a single allocation for each
variable (at first mpz call using it as the destination operand), and no
realloc. So the typical lifetime of an mpz variable is changed from
malloc (one limb) + realloc + free, to only malloc + free.
> The only possible cause I'm
> thinking of, would be a succession of reallocations in a loop
> because the mpz_t's are growing.
That's a larger overhead of reallocation and copying.
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
More information about the gmp-devel
mailing list