Pip Cet wrote:

>> -       num += mpz_mod_ui (z, XBIGNUM (n)->value, cycle_length);
>> +       num += mpz_mod_ui (mpz[0], XBIGNUM (n)->value, cycle_length);
> 
> I think it would be best to use mpz_div_ui here (despite its name, it
> returns the remainder of the division specified by its arguments).

I assume you meant mpz_tdiv_ui. Yes, thanks, that should be a bit faster. 
Likewise for mpz_tdiv_r instead of mpz_mod, for --with-wide-int platforms. I 
installed the attached.

> Are you sure it wouldn't be possible to get the performance gains your
> patch gives us without introducing global temporaries, such as by
> using mpz_swap efficiently? Is this worth investigating, maybe, or do
> you prefer global temporaries for another reason?

I'm no fan of these temps, but the GMP mpz API does push hard in the direction 
of preinitialized temps if we want efficiency, as the overhead for small 
operands is the first thing listed in 
<https://gmplib.org/manual/Efficiency.html>. And in the context of Emacs, 
doesn't mpz_swap rely on having preinitialized temps? How would we use mpz_swap 
efficiently without having preinitialized temps? Unfortunately in C I don't see 
how to have preinitialized temps without making them "global" in some sense; we 
could easily make them Emacs-thread-local if necessary, but they'd still be 
"global" to the thread.

I mainly introduced global temporaries to fix memory leaks when a bignum 
calculation overflows past integer-width or when memory is exhausted. It would 
also be possible to avoid these leaks by putting a record_unwind_protect of some 
sort around every bignum calculation, but that would slow things down significantly.

As a side effect, somewhat to my surprise, I found that global temps made the 
code simpler and easier to understand. I still don't like the "global" part of 
them, though, and perhaps with further hacking we can find some way to make them 
local while keeping the code simple and efficient.