Was the profiling done in an app that was using the database in a realistic manner? I'd be surprised if string.format really matters all that much in a real-world scenario. 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. Certainly from a user perspective, there is no difference between .047 seconds and .036 seconds; it's too small a time scale to notice. 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. Again, not enough evidence to support that these are real world numbers using a real app with real DB usage.
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
