[
https://issues.apache.org/jira/browse/TAP5-2332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14004543#comment-14004543
]
Jochen Kemnade edited comment on TAP5-2332 at 5/21/14 10:03 AM:
----------------------------------------------------------------
Just made some tests myself (on Java 7 FWIW). They are not too scientific but
anyway:
I concatenated {{"foo"}} and {{"bar"}} in a for loop 1.000.000 times:
simple concat with {{+}}: ~ 500ms
my simple concat function: ~400ms
my optimized concat function: ~430ms
{{String.format}}: ~7.300ms
My simple concat function uses StringBuilders, allocated with the correct size.
My optimized concat function has become rather complicated. It's about 60
lines, checks for null values, and checks if only one of the strings is
non-empty and returns that one in that case and only uses StringBuilders
(again, allocated with the correct size) when multiple arguments are non-empty.
For 10 Strings, including empty, short and longer (~30 chars) ones:
simple concat with {{+}}: ~3.000 ms
my simple concat function: ~2.000 ms
my optimized concat function: ~3.000 ms
{{String.format}}: ~30.000 ms
was (Author: jkemnade):
Just made some tests myself (on Java 7 FWIW). They are not too scientific but
anyway:
I concatenated {{"foo"}} and {{"bar"}} in a for loop 1.000.000 times:
simple concat with {{+}}: ~ 500ms
my simple concat function: ~400ms
my optimized concat function: ~430ms
{{String.format}}: ~7.300ms
My simple concat function uses StringBuilders, allocated with the correct size.
My optimized concat function has become rather complicated. It's about 60
lines, checks for null values, and checks if only one of the strings is
non-empty and returns that one in that case and only uses StringBuilders
(again, allocated with the correct size) when multiple arguments are non-empty.
For 10 Strings, including empty, short and longer (~30 chars) ones:
simple concat with {{+}}: ~3.000 ms
my simple concat function: ~2.000 ms
my optimized concat function: ~3000 ms
{{String.format}}: ~30.000 ms
> Get rid of String.format usage
> ------------------------------
>
> Key: TAP5-2332
> URL: https://issues.apache.org/jira/browse/TAP5-2332
> Project: Tapestry 5
> Issue Type: Improvement
> Reporter: Michael Mikhulya
> Priority: Minor
> Labels: performance
> Attachments: 0001-TAP5-2332-get-rid-of-String.format-usage.patch
>
>
> During profiling I found that String.format provides much load on CPU.
> In many cases in Tapestry String.format can be easily replaced with simple
> String concatenation.
> Simple JMH (http://openjdk.java.net/projects/code-tools/jmh/) test
> {code:java}
> public class FormatVsConcat {
> private static final String format = "This is a test string with %s";
> private static final String concat1 = "This is a test string with ";
> private static final String concat2 = "test word";
> @GenerateMicroBenchmark
> public String format() {
> return String.format(format, concat2);
> }
> @GenerateMicroBenchmark
> public String concat() {
> return concat1 + concat2;
> }
> }
> {code}
> shows, that concatenation is 366(!) times faster.
> I removed only hot places in tapestry and get following results with apache
> benchmark:
> *Not patched* tapestry version:
> Requests per second: *21.38 /sec* (mean)
> Time per request: *46.764 [ms]* (mean)
> *Patched* tapestry version:
> Requests per second: *27.77 /sec* (mean)
> Time per request: *36.013 [ms]* (mean)
> So we gained 10ms per request or 20% of rendering time.
> If you don't mind I would like to get rid of String.format in all places of
> Tapestry and provide patch. I fixed only hot places which appeared during
> ab-profiling of one concrete page. So it is very likely that not all hot
> places were found and fixed.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
