RFR 4641897: Faster string conversion of large integers (original) (raw)

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.

Peter

More information about the core-libs-dev mailing list