[
https://issues.apache.org/jira/browse/TAP5-2337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14322142#comment-14322142
]
Michael Mikhulya commented on TAP5-2337:
----------------------------------------
Thank you [~thiagohp].
I totally agree with such approach.
Unfortunatelly I will be on vacation next two weeks and can't prepare patch
soon.
Is it possible to help newbies like me?
It is not hard to make minor changes to idea, so it satisfy all the rules. As
result of it we will improve tapestry.
Instead of help I see some opposition from you. (May be I'm wrong here, but it
is how I feel this situation.)
Also some patches aren't reviewed for a long time.
Both things don't help in involving new persons to project.
I would like to say "Thank you" to [~jkemnade] for fast review/commit of simple
patches and help in polishing these patches.
But I wait for review of other patches. It would be good if review will show
that I was wrong somewhere, so I can change it.
Without it I'm not motivated to prepare new patches and check new ideas.
Sorry, for this comment. But I want to make tapestry to be better/faster.
Please don't answer to comment. I don't want any flame. Please help with
reviewing or polishing my patches.
Thank you.
> 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)
