speed of mpz_odd_p and lazy allocation

[Niels Möller]

Marc Glisse <marc.glisse at inria.fr> writes:

> That's where move constructors appear. One can now define something
> that is similar to a copy constructor, except that it leaves the
> original object in some arbitrary state, so in particular it can steal
> its resources.

I don't know at all if it's possible to coerce std::vector to do this,
but what do you think about the following procedure?

1. Allocate the new vector, mpz_init all elements (may suffer memory
   allocation errors).

2. mpz_swap elements in the new and old vector. It will "steal"
   resources efficiently, and as far I'm aware, it can't fail.

3. Now mpz_clear the old elements.

4. Initialize and assign the new element being appended, etc. In any
   case, you have an intact vector with the original data.

Sure, not very pretty to have to allocate a new limb for each mpz_t in
step 1, just to free them in step 3. But at least it's O(n) work (n is the
length of the vector).

To me, it would make sense to let mpz_init not allocate storage, but
point to a shared limb, possibly read-only, and set _mp_alloc to zero.
But I haven't reviewed the code to see where _mp_d[0] is written without
checking _mp_alloc. So I don't know if an extra branch in those places,
to support lazy allocation, matters for performance.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.