tapestry-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Mikhulya (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (TAP5-2337) Reduce number of calls of AbstractStringBuilder.expandCapacity
Date Mon, 09 Feb 2015 08:48:35 GMT

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

Michael Mikhulya edited comment on TAP5-2337 at 2/9/15 8:47 AM:
----------------------------------------------------------------

There is more info regarding this issue.
It was found that Element.toMarkup is in top of excessive garbage allocation (please look
attachment).

Is it possible to make minor API changes in major release to reduce GC overhead?


was (Author: mihasik):
There is more info regarding this issue.
It was found that Element.toMarkup is in top of excessive garbage allocation.

Is it possible to make minor API changes in major release to reduce GC overhead?

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

Mime
View raw message