[ 
https://issues.apache.org/jira/browse/TAP5-2337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14319988#comment-14319988
 ] 

Thiago H. de Paula Figueiredo commented on TAP5-2337:
-----------------------------------------------------

Hi!

I'll repeat myself: changing method signatures of non-internal classes and 
interfaces breaks backward compatibility, which is a major concern in Apache 
Tapestry, and something that should be only done when there's a huge need, and 
I don't think that's the case here, not even close, as it's a 1% improvement. 
The patch, as it is now, will get a -1 vote from me if it's applied to Git.

On the other hand, instead of changing the existing methods, there's another 
approach: keep them, mark them as deprecated, create new methods, and change 
the code that uses the deprecated ones to use the new, more efficient methods. 
That's the approach which has being used in the project. 

> 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)

Reply via email to