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
