Looks good.
On 09/23/2014 02:07 PM, Claes Redestad wrote:
How about:
// Specialized localization of exponents, where the source value can only
// contain characters '0' through '9', starting at index offset, and no
// group separators is added for any locale.
private void
Shouldn't this one be at the same class (FormatSpecifier?) as the
localizedMagnitudeExp?
the webrev shows it is one level up.
Btw, when we are here, maybe we can just remove the FormatSpecifier.getZero(),
it appears
we have a static version already at Formatter level.
On 09/24/2014 10:41 AM,
On 2014-09-24 20:14, Xueming Shen wrote:
Shouldn't this one be at the same class (FormatSpecifier?) as the
localizedMagnitudeExp?
the webrev shows it is one level up.
Nice catch!
Btw, when we are here, maybe we can just remove the
FormatSpecifier.getZero(), it appears
we have a static
On 09/24/2014 01:33 PM, Claes Redestad wrote:
Updated localizedMagnitudeExp to reside in FormatSpecifier, leaving getZero
alone:
http://cr.openjdk.java.net/~redestad/8050142/webrev.10/
I think we are good to go :-) I was wrong on getZeron.
I can push this change, Claes.
-Brent
I had to make an update to satisfy jcheck, and neglected to specify the
user when re-committing, so I'm listed as the author. Sorry!
-Brent
On 9/24/14 2:16 PM, Brent Christian wrote:
I can push this change, Claes.
-Brent
On 2014-09-23 21:14, Xueming Shen wrote:
On 09/22/2014 12:43 PM, Claes Redestad wrote:
Hi,
Sherman pointed out that there was a path that could actually take a
minor performance hit from this patch,
which would be unacceptable. This version takes the minimal approach
to addressing this by
Ouch... but wait... the char[] returned from
sun.misc.FormattedFloatingDecimal.getExponent() can never contain a '.',
so we'll never find a dot here. Remove the dead code or fix the logic?
/Claes
On 2014-09-23 21:30, Xueming Shen wrote:
Also the logic in the loop of localizedMagnitudeExp()
I don''t think an exponent should ever have a dot', it always a signed
integer. I think we can
just remove the dead code, maybe put some wording to explain why no group, no
dot here.
-Sherman
On 09/23/2014 12:42 PM, Claes Redestad wrote:
Ouch... but wait... the char[] returned from
when converting case. That
is probably not a change for this issue.
Jason
Date: Mon, 14 Jul 2014 17:40:41 +0200
From: claes.redes...@oracle.com
To: core-libs-dev@openjdk.java.net
Subject: Re: RFR [9]: 8050142: Optimize java.util.Formatter
Hi,
final
for this issue.
Jason
Date: Mon, 14 Jul 2014 17:40:41 +0200
From: claes.redes...@oracle.com
To: core-libs-dev@openjdk.java.net
Subject: Re: RFR [9]: 8050142: Optimize java.util.Formatter
Hi,
final(?) webrev: http://cr.openjdk.java.net/~redestad
Date: Mon, 14 Jul 2014 17:40:41 +0200
From: claes.redes...@oracle.com
To: core-libs-dev@openjdk.java.net
Subject: Re: RFR [9]: 8050142: Optimize java.util.Formatter
Hi,
final(?) webrev: http://cr.openjdk.java.net/~redestad/8050142/webrev.2
Thanks
On 07/14/2014 12:07 PM, Claes Redestad wrote:
Hi,
please review this patch which optimizes away some allocations from
java.util.Formatter and achieve 1.1-1.3x speedups of micros targetting
String.format. See bug for more details.
webrev:
Hi,
good suggestions, I'll incorporate them.
/Claes
On 2014-07-14 13:08, Andrej Golovnin wrote:
Hi Claes,
in the method Formatter$FormatSpecifier#justify(String) you can
pre-calculate the capacity of the StringBuilder to avoid array
copying, e.g. instead of
2931
Hi Peter,
On 2014-07-14 13:25, Peter Levart wrote:
On 07/14/2014 12:07 PM, Claes Redestad wrote:
Hi,
please review this patch which optimizes away some allocations from
java.util.Formatter and achieve 1.1-1.3x speedups of micros
targetting String.format. See bug for more details.
On 07/14/2014 01:29 PM, Claes Redestad wrote:
Hi Peter,
On 2014-07-14 13:25, Peter Levart wrote:
On 07/14/2014 12:07 PM, Claes Redestad wrote:
Hi,
please review this patch which optimizes away some allocations from
java.util.Formatter and achieve 1.1-1.3x speedups of micros
targetting
Hi Peter,
On 2014-07-14 14:05, Peter Levart wrote:
On 07/14/2014 01:29 PM, Claes Redestad wrote:
Hi Peter,
On 2014-07-14 13:25, Peter Levart wrote:
On 07/14/2014 12:07 PM, Claes Redestad wrote:
Hi,
please review this patch which optimizes away some allocations
from java.util.Formatter
Hi again,
updated webrev: http://cr.openjdk.java.net/~redestad/8050142/webrev.1
changes:
- specify capacity on line 2931 as suggested by Andrej Golovnin
- exp.append(0) - exp.append('0') on line 3781
- merged append+justify into appendJustified as suggested by Peter Levart
- replaced the
On 07/14/2014 02:17 PM, Claes Redestad wrote:
If you're in a really hyper-optimizing mood, you could also eliminate
construction of ArrayList in parse():
http://cr.openjdk.java.net/~plevart/jdk9-dev/Formatter/webrev.02/
Have you measured this to have a real effect? I'm not convinced it
A very minor one:
2704 if (Character.isUpperCase(conv))
2705 f.add(Flags.UPPERCASE);
2706 c = Character.toLowerCase(conv);
maybe
2704 if (Character.isUpperCase(conv)) {
2705 f.add(Flags.UPPERCASE);
2706
Hi Claes,
it looks good. And I have one minor improvement. Take look at the following
lines of the method FormatSpecifier#hexDouble(double, int):
3532 // Get exponent and append at the end.
3533 String exp = res.substring(idx + 1);
3534
Hi Andrej,
while the change seems reasonable, I can't find any usage of %a/%A in
the JDK and haven't even covered it in my micros. :-) Also, it could be
further improved with 8041972 to turn:
3533 String exp = res.substring(idx + 1);
3534
Yes, might be worth addressing just for correctness/readability.
/Claes
On 07/14/2014 03:02 PM, Ivan Gerasimov wrote:
A very minor one:
2704 if (Character.isUpperCase(conv))
2705 f.add(Flags.UPPERCASE);
2706 c = Character.toLowerCase(conv);
Hi,
final(?) webrev: http://cr.openjdk.java.net/~redestad/8050142/webrev.2
Thanks in advance for reviews. I also need a volunteer to sponsor
this. :-)
/Claes
On 07/14/2014 04:21 PM, Claes Redestad wrote:
Yes, might be worth addressing just for correctness/readability.
/Claes
On
case. That is probably not
a change for this issue.
Jason
Date: Mon, 14 Jul 2014 17:40:41 +0200
From: claes.redes...@oracle.com
To: core-libs-dev@openjdk.java.net
Subject: Re: RFR [9]: 8050142: Optimize java.util.Formatter
Hi,
final(?) webrev
Date: Mon, 14 Jul 2014 17:40:41 +0200
From: claes.redes...@oracle.com
To: core-libs-dev@openjdk.java.net
Subject: Re: RFR [9]: 8050142: Optimize java.util.Formatter
Hi,
final(?) webrev: http://cr.openjdk.java.net/~redestad/8050142/webrev.2
Thanks in advance for reviews. I also need
26 matches
Mail list logo
