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

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

The numbers are not too stable, they change from one execution to the next.
What I can say is that for me, the simple StringBuilder version is always 
faster than using {{+}}. In my last few tests, the optimized version was about 
as fast as the simple one.
My proposal is that we add the following method to {{IOCUtilities}} and use it 
whenever possible instead of {{String.format}}:
{code}
  public static String concat(final CharSequence first, final CharSequence 
second, final CharSequence... more) {
    if (first == null || second == null) {
      throw new NullPointerException("Null values are not supported");
    }
    for (CharSequence cs : more) {
      if (cs == null) {
        throw new NullPointerException("Null values are not supported");
      }
    }
    int overallLength = first.length() + second.length();
    for (CharSequence charSequence : more) {
      overallLength += charSequence.length();
    }
    StringBuilder sb = new StringBuilder(overallLength);
    sb.append(first);
    sb.append(second);
    for (CharSequence charSequence : more) {
      sb.append(charSequence);
    }
    return sb.toString();

  }
{code}

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

Reply via email to