RFR (S): 8065070: (fmt) Avoid creating substrings when building FormatSpecifier
Claes Redestad
claes.redestad at oracle.com
Mon Nov 17 11:49:19 UTC 2014
On 2014-11-17 11:45, Aleksey Shipilev wrote:
> On 11/17/2014 02:09 AM, Claes Redestad wrote:
>> http://cr.openjdk.java.net/~redestad/8065070/webrev.00
>> https://bugs.openjdk.java.net/browse/JDK-8065070
> (Not a Reviewer) The change looks very sane given the capture ranges are
> already available in Matcher.I wonder if you want to cache m.start()
> and m.end() in locals while you are at it -- I would think this amounts
> to moving tTStart, tTEnd a few lines before.
Thanks for taking a look at this!
Not sure how you mean locally caching m.start(idx) would
improve things, as we never reuse the same start/end values.
Perhaps rewriting to something like this would make the code
cleaner:
index(s, m.start(1), m.end(1));
flags(s, m.start(2), m.end(2));
width(s, m.start(3), m.end(3));
precision(s, m.start(4), m.end(4));
int tTStart = m.start(5);
if (tTStart >= 0) {
dt = true;
if (s.charAt(tTStart) == 'T') {
f.add(Flags.UPPERCASE);
}
}
conversion(s.charAt(m.start(6)));
(I noticed that getting and checking tTEnd is basically redundant,
since the formatSpecifier regex guarantees either one char or
nothing is matched for that group)
>
>> @Benchmark
>> public String formatIndexedDoubleExpr() {
>> return String.format("%1$2.3f", pi);
>> }
>>
>> before: 1082.564 18.943 ops/ms
>> after: 1309.945 18.219 ops/ms # 1.21x
> So this measures both the formatter setup costs and the actual
> formatting, right? 1.21x on that composite operation means even more
> speedup on formatter setup?
Yes and yes (by deduction, since formatting code is unchanged).
It's not possible to isolate setup from formatting using the
public API, since formatter string parse is done in the private
Formatter.format method.
I guess copying the setup code into the benchmark and running it
in isolation is feasible, but since this setup cost is paid on every
format operation even if you break out and use a standalone
Formatter, it currently makes sense to focus on the composite cost.
/Claes
>
> Thanks,
> -Aleksey.
>
>
>
More information about the core-libs-dev
mailing list