[
https://issues.apache.org/jira/browse/TAP5-2332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14006027#comment-14006027
]
Jochen Kemnade commented on TAP5-2332:
--------------------------------------
Sorry for bringing new crazy ideas into the discussion still, but if we created
a LazyConcatenated class that implemented CharSequence and used CharSequence in
the signature of relevant methods (like the descriptions in OperationTracker),
we'd have to concatenate the strings only if we actually need the concatenated
result (in case of an exception or debug logging). And we wouldn't even break
backward compatibility... Alright, just kidding. Or am I...? :-D
> Optimize String concatenation performance
> -----------------------------------------
>
> Key: TAP5-2332
> URL: https://issues.apache.org/jira/browse/TAP5-2332
> Project: Tapestry 5
> Issue Type: Improvement
> Reporter: Michael Mikhulya
> Assignee: Jochen Kemnade
> Priority: Minor
> Labels: performance
> Attachments: 0001-TAP5-2332-get-rid-of-String.format-usage.patch,
> profile-patched.png, profile-vanilla.png
>
>
> 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)
