Am 21.05.2014 14:22, schrieb Robert Zeigler:
Was the profiling done in an app that was using the database in a realistic 
manner?

Which database do you mean?

And I'm not sure the I improvements in throughput posted by the original poster 
are enough to justify switching out the entire code base from using 
string.format.

Sure, we don't want to replace every possible use of String.format. Just the places where it's used to concatenate Strings, like in String.format("%s%s", string1, string2) or

And if you're in a scenario where serving 28 requests per second vs 22 requests 
per second really matters, your time would be better spent using replication.

I have a different opinion there. If we can make a simple change (it's nothing critical or overly complicated IMO) to improve request throughput by a two-digit percentage, I'm in favor of doing it. Also, I'm pretty confident these are 28 vs. 22 requests per second per handler thread.

Jochen



Robert

GATAATGCTATTTCTTTAATTTTCGAA

On May 21, 2014, at 6:30 AM, "Jochen Kemnade (JIRA)" <j...@apache.org> wrote:


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

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org
For additional commands, e-mail: dev-h...@tapestry.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org
For additional commands, e-mail: dev-h...@tapestry.apache.org

Reply via email to