Thanks Sherman; given the at most marginal performance cost, I'll push
the changes in the next day or two.
-Joe
On 02/06/2012 05:02 PM, Xueming Shen wrote:
Joe,
I did some non-scientific measure of the performance. test1() is to
measure the change
in a real "listing" operation on a ZipInput
Joe,
I did some non-scientific measure of the performance. test1() is to
measure the change
in a real "listing" operation on a ZipInputStream and test2() is a pure
access on the byte[]
directly. I don't see any significant difference on performance in both
-client and -server
vm. I would assu
On Feb 3, 2012, at 8:37 PM, Krystal Mok wrote:
> Hi Tom,
>
> Yes, I'm sorry for not including enough context when cc'ing.
>
> The original discussion thread starts from [1]. The webrev is at [2].
>
> For the string concats in multiplyExact():
> * the StringBuilder doesn't escape
> * it's only
I'm with Roger on this.
> Sorry, but I can't agree with this. Developers get negation of numbers
> wrong all the time by ignoring the special case. Its a big source of
> hidden bugs. Increment/decrement are replaceable by add/subtract (with
> less readability), but negate is not.
First of all, ne
On 6 February 2012 21:16, Roger Riggs wrote:
> * Removed the negateExact methods since they don't pull their weight
> in the API,
> simple tests for MIN_VALUE and MAX_VALUE can be done by the
> developer more efficiently.
Sorry, but I can't agree with this. Developers get negation of numbe
On 6 February 2012 21:15, Roger Riggs wrote:
>> Separately but related, there are missing methods in BigInteger,
>> longValueExact() and intValueExact()
>
> BigInteger provides a bitLength method than be tested to see if the result
> would overflow. That's a better API than an ArithmeticException
Looks good to me (emcmanus). One really trivial thing is that
Math.java:830 is indented one space too far. I thought that the common
(int)value subexpression could be put in a variable in toIntExact but
it turns out that javac generates more code in that case.
Éamonn
On 6 February 2012 13:16, R
Thanks for the review and comments:
The comments and suggestions are included in the updated webrev:
http://cr.openjdk.java.net/~rriggs/6708398.1
* Corrected error in multipleExact(long,long) with the special case
Long.MIN_VALUE * -1.
* Verified that retaining the optimization for small
Éamonn, Thanks for the detailed review.
I did some simple performance tests with and without the optimization test.
With the optimization, performance was nearly doubled. The individual
tests for x or y ==1 did not improve performance. Those cases are
likely optimized inside the divide operat
On 02/03/2012 10:23 AM, Stephen Colebourne wrote:
I prefer the method naming safeAdd/safeNegate/safeMultiply (I think
they are a lot clearer), but can live with the ones proposed (which
are somewhat linked to BigInteger/BigDecimal).
The method names should start with the operation.
I would like
10 matches
Mail list logo
