[TODO] Update about mpz_t caching (mpz_t pool).

git-svn-id: svn://scm.gforge.inria.fr/svn/mpfr/trunk@10739 280ebfd0-de03-0410-8827-d642c229c3f4

1 files changed, 10 insertions, 12 deletions

diff --git a/TODO b/TODO
index bb2de8d69..6207c2995 100644
--- a/TODO
+++ b/TODO
@@ -526,11 +526,12 @@ Table of contents:
 
 - use symbol versioning.
 
-- check whether mpz_t caching is necessary. Timings with -static with
-  details about the C / C library implementation should be put somewhere
-  as a comment in the source or in the doc. Using -static is important
-  because otherwise the cache saves the dynamic call to mpz_init and
-  mpz_clear; so, what we're measuring is not clear. See thread:
+- check whether mpz_t caching (pool) is necessary. Timings with -static
+  with details about the C / C library implementation should be put
+  somewhere as a comment in the source or in the doc. Using -static
+  is important because otherwise the cache saves the dynamic call to
+  mpz_init and mpz_clear; so, what we're measuring is not clear.
+  See thread:
     https://gmplib.org/list-archives/gmp-devel/2015-September/004147.html
   Summary: It will not be integrated in GMP because 1) This yields
   problems with threading (in MPFR, we have TLS variables, but this is
@@ -546,13 +547,10 @@ Table of contents:
     arccos(x)  took 0.043580 ms (32767 eval in 1428 ms)
     arctan(x)  took 0.035401 ms (32767 eval in 1160 ms)
   mpfr_acos doesn't use mpz, but calls mpfr_atan, so that the issue comes
-  from mpfr_atan, which uses mpz a lot. But there are very few mpz_init
-  and mpz_clear (just at the end). So, the differences in the timings are
-  very surprising, even with a bad malloc implementation. Or is the reason
-  due to that due to mpz_t caching, the mpz_t's are preallocated with a
-  size that is large enough, thus avoiding internal reallocations in GMP
-  (with memory copies)? In such a case, mpz_t caching would not be the
-  solution, but mpz_init2 (see GMP manual, 3.11 "Efficiency").
+  from mpfr_atan, which uses mpz a lot. The problem mainly comes from the
+  reallocations in GMP because mpz_init is used instead of mpz_init2 with
+  the estimated maximum size. Other places in the code that uses mpz_init
+  may be concerned.
 
 - in tsum, add testcases for mpfr_sum triggering the bug fixed in r9722,
   that is, with a large error during the computation of the secondary term