Ian Rogers wrote:
Hi,

please give your comments on the attached patch. It tries to reduce the size of char[] for strings used to hold numbers. It changes Float/Double equals to use bit based comparisons rather than division. It increases the use of valueOf methods. It adds a cache of values from -128 to 127 for Long. It adds a cache of the values of zero and one to Float and Double.

The string size is an estimate. For decimal numbers it will divide the value repeatedly by 8, causing the string length to be over estimated by a character for values like 999. This string size is still better than the current estimate of 33 characters. It also avoids the use of division (shifts are used) and/or lookup tables.


I would like to know your motivation for doing this. Do you have any evidence that this will reduce memory usage and speed up real applications?


That said, in our gcj-3.4 based application, we had to create a cache of Integers because we were creating large numbers of them all with a small set of values.

So in principle this could be a good approach, but I don't know if we can assume that there is universal benefit from a patch like this. Can you point to any benchmarks where this helps?


Thanks,
David Daney

Reply via email to