You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by "Jochen Kemnade (JIRA)" <ji...@apache.org> on 2015/02/13 11:59:11 UTC
[jira] [Commented] (TAP5-2337) Reduce number of calls of
AbstractStringBuilder.expandCapacity
[ https://issues.apache.org/jira/browse/TAP5-2337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14319946#comment-14319946 ]
Jochen Kemnade commented on TAP5-2337:
--------------------------------------
We're not planning to do a major release anytime soon (that would be 6.0).
However, this new information might change things slightly.
My current thoughts on the situation: The patch changes signatures of two methods with default visibiliy (Element and Attribute in the {{org.apache.tapestry5.dom}} package. I'd be okay with that. The other change is in {{MarkupModel}}, which is a public interface. I'm a bit concerned about that one. What if we create a service or static utility method {{public void encodeQuoted(String content, Appendable appendable, boolean useApostropheForAttributes)}} and use that in {{AbstractMarkupModel}}, {{Element}} and {{Attribute}}? The latter ones could use {{MarkupModel.getAttributeQuote()}} to determine the value for the {{useApostropheForAttributes}} parameter. If I've got things right in my head, then we wouldn't have to change the signature of {{MarkupModel}}.
> 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.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)