On Sun, 24 Sep 2023 11:59:51 GMT, 温绍锦 <d...@openjdk.org> wrote:
>> @cl4es made performance optimizations for the simple specifiers of >> String.format in PR https://github.com/openjdk/jdk/pull/2830. Based on the >> same idea, I continued to make improvements. I made patterns like %2d %02d >> also be optimized. >> >> The following are the test results based on MacBookPro M1 Pro: >> >> >> -Benchmark Mode Cnt Score Error Units >> -StringFormat.complexFormat avgt 15 1862.233 ? 217.479 ns/op >> -StringFormat.int02Format avgt 15 312.491 ? 26.021 ns/op >> -StringFormat.intFormat avgt 15 84.432 ? 4.145 ns/op >> -StringFormat.longFormat avgt 15 87.330 ? 6.111 ns/op >> -StringFormat.stringFormat avgt 15 63.985 ? 11.366 ns/op >> -StringFormat.stringIntFormat avgt 15 87.422 ? 0.147 ns/op >> -StringFormat.widthStringFormat avgt 15 250.740 ? 32.639 ns/op >> -StringFormat.widthStringIntFormat avgt 15 312.474 ? 16.309 ns/op >> >> +Benchmark Mode Cnt Score Error Units >> +StringFormat.complexFormat avgt 15 740.626 ? 66.671 ns/op >> (+151.45) >> +StringFormat.int02Format avgt 15 131.049 ? 0.432 ns/op >> (+138.46) >> +StringFormat.intFormat avgt 15 67.229 ? 4.155 ns/op >> (+25.59) >> +StringFormat.longFormat avgt 15 66.444 ? 0.614 ns/op >> (+31.44) >> +StringFormat.stringFormat avgt 15 62.619 ? 4.652 ns/op >> (+2.19) >> +StringFormat.stringIntFormat avgt 15 89.606 ? 13.966 ns/op >> (-2.44) >> +StringFormat.widthStringFormat avgt 15 52.462 ? 15.649 ns/op >> (+377.95) >> +StringFormat.widthStringIntFormat avgt 15 101.814 ? 3.147 ns/op >> (+206.91) > > 温绍锦 has updated the pull request incrementally with one additional commit > since the last revision: > > refactor and cache single conversion FormatSpecifier > Please don't pile on new refactorings and improvements on a PR that has been > opened for review. Better to let things brew as a draft for a bit if you're > not sure you're done before opening the PR for review, then once it's been > opened (like this one) consider preparing follow-up PR instead of refactoring > as you go. > > Specifically I'm not sure > [0d977b2](https://github.com/openjdk/jdk/commit/0d977b2febe455f4535e6ee2cb19d3b168d764e3) > is a good idea and would like you to roll those changes back. Object pooling > for trivial, short-lived objects are considered an anti-pattern, as they add > references to old GC generations and share many of the same drawbacks as > lookup tables, such as increased cache traffic. Showing great wins on > microbenchmarks while being a wash or even regressing real applications. Sorry, I will pay attention to it in the future and modify it in the open review code. I have revert commit to #0d977b2. I agree with your view on the performance issues of old reference. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15776#issuecomment-1732567054
