tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jochen Kemnade (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (TAP5-2332) Optimize String concatenation performance
Date Thu, 22 May 2014 14:13:02 GMT

    [ https://issues.apache.org/jira/browse/TAP5-2332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14005943#comment-14005943
] 

Jochen Kemnade commented on TAP5-2332:
--------------------------------------

Yes, and if the test hadn't been adapted to the new behavior of the main source set, it would
have failed. The change in the test file doesn't even have something to do with string concatenation
and it is unrelated to the discussion.
And I think that Knuth's quote can only applied here with some force. It's not as if I wanted
to introduce 100 lines of cryptic code to solve some tiny part of a complicated problem. It's
about /string concatenation/. The code I proposed is simple, really simple. And it can be
tested very well. Besides, if you put it like that, String.format is also premature optimization
of concatenating with {{+}}.
And please don't comment on that old patch anymore, I said I'll create a new one (without
OptionModelImpl.toString(), as I already said). You can tear that apart if you like.
That said, l suggest we stop discussing about abstract software development principles and
get back to the concrete topic.

> 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)

Mime
View raw message