[
https://issues.apache.org/jira/browse/TAP5-2332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14004991#comment-14004991
]
Michael Mikhulya commented on TAP5-2332:
----------------------------------------
Jochen, thank you for your investigation.
Your idea with introducing IOCUtilities.concat seems good for me. It not only
encapsulate logic with possiblity to replace implementation in one place, but
it also provides examples in code. So developers will see it, look at javadoc
and recognize why this approach is used (so idea will not be lost with time).
It is especially good that your implementation is faster than String
concatenation.
{quote}
If it's shown that this improvement noticibly speeds up a realistic
application, I'm all for it.
{quote}
Lance, I profiled real application which I'm work on at my paid job. I can
provide a link to site privately if you want. Actually I profiled only the page
that is most frequently used by real customers. So it is very probably that I
didn't find all low hanging fruits. Application uses in memory data grid to
cache important data. So during profiling there was no any SQL queries.
As you see, TAP5-2332 + TAP5-2333 saves 20ms per request. It is rather
noticable time and it is comparable with time required to execute *several* SQL
queries.
There is a link to Web Framework Bencharmks:
http://www.techempower.com/benchmarks/
As you can see with time more and more frameworks appear which are faster then
tapestry.
So I can't wait to see how tapestry will show itself when all my patches/ideas
will be applied.
In my case page become almost twice faster.
I would like to make more profiling especially in other areas (e.g. for json
serialization) and I have time for it during next week.
But before making additional profiling I would like to see that my work is
merged to master.
It would be great If patches are merged to stable version too and new stable
version is released.
We didn't migrated to tapestry-5.4 yet at our company, so I'm forced to do
profiling on stable version.
Jochen, is it possible to apply patches/ideas during this week?
In June I will be busy on new 'big' tasks at my job and I don't have time for
profiling at home (I devote almost all my free time to my family, which was
recently expanded with the child.)
> 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)
