[
https://issues.apache.org/jira/browse/TAP5-2337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14329197#comment-14329197
]
Michael Mikhulya commented on TAP5-2337:
----------------------------------------
Thank you, [~jkemnade].
In general looks good for me.
{code:java}
TapestryInternalUtils.encodeQuoted(value, appendable,
model.getAttributeQuote() == '\'');
{code}
seems a little weird because it leaks internal logic of MarkupModel. Is it
possible to add method {{MarkupModel.useApostropheForAttributes}}?
Also following method is called repeatedly in many places:
{code:title=AbstractModel.java}
public char getAttributeQuote()
{
return useApostropheForAttributes ? '\'' : '"';
}
{code}
It is possible to add {{attributeQuote}} private final field and don't
recalculate it repeatedly.
I'm not sure, but may be adding new method (and making obsolete another one) to
MarkupModel is not a bad idea. It will make possible to evolve other code. Also
without it code become more complex.
> Reduce number of calls of AbstractStringBuilder.expandCapacity
> --------------------------------------------------------------
>
> Key: TAP5-2337
> URL: https://issues.apache.org/jira/browse/TAP5-2337
> Project: Tapestry 5
> Issue Type: Improvement
> Reporter: Michael Mikhulya
> Priority: Minor
> Labels: performance
> Attachments:
> 0001-TAP5-2337-Reduce-number-of-calls-of-AbstractStringBu-jk.patch,
> 0001-TAP5-2337-Reduce-number-of-calls-of-AbstractStringBu.patch,
> Tapestry-StringBuilder.png
>
>
> During profiling of Tapestry framework I found that
> AbstractStringBuilder.expandCapacity is called very frequently.
> There is a patch that get rid of creation StringBuilder with following calls
> of expandCapacity (which allocate memory and copy current content into it).
> I have to thank Dmitriy Ilyin, who helped me to investigate the issue and to
> find the simplest solution (actually we get a little bit less code while
> improving performance).
> With this improvement time per request decreased on 0.5ms (1% of overall
> time)on our test. All measurements were done with apache benchmark after warm
> up phase.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
