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.
