RFR 4641897: Faster string conversion of large integers

Peter Levart peter.levart at gmail.com
Tue Jun 25 22:12:32 UTC 2013

On 06/25/2013 09:09 PM, Alan Eliasen wrote:
> On 06/25/2013 12:13 PM, Peter Levart wrote:
>>              else { // resizing
>>                  // increase by factor of 1.5 (like ArrayList)
>>                  int newLength = oldLength + (oldLength >> 1);
>     We probably don't ever want to extend any row of this cache any more
> than we need to.  The entries in each row of the cache, say for base 10,
> are 10^(2^n) which obviously grows super-exponentially with n.  (And the
> time to perform each squaring to get successive terms will grow
> quadratically or at least subquadratically on top of that, along with
> memory usage which squares with each additional term.)  So we should
> never resize to more entries in that table than we need, and we should
> try to avoid recalculating entries in that table in multiple threads, as
> the cost to calculate them can be high.
>     As I noted years ago, the caching behavior is certainly going to be
> one of the most controversial parts of BigInteger improvements.  :)

Hi Alan, I'll answer in the other thread.


More information about the core-libs-dev mailing list