[
https://issues.apache.org/jira/browse/SLING-5117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14956786#comment-14956786
]
Joel Richard commented on SLING-5117:
-------------------------------------
[~cziegeler], do you think the problem could have been the following one?
https://bz.apache.org/bugzilla/show_bug.cgi?id=50228
I have already quickly tested the pool and at a first glance it looked fine.
Before the PageContext is reused, it resets the internal state of it. Since it
resets even the internal state of the JspWriter, it can reuse the same object
and therefore we could also reuse the PrintWriter. I don't see a reason why
this should be a problem for JSPs/lead to memory leaks (unless there are
further bugs similar to #50228).
> Reuse PrintWriter to avoid initialisation overhead
> --------------------------------------------------
>
> Key: SLING-5117
> URL: https://issues.apache.org/jira/browse/SLING-5117
> Project: Sling
> Issue Type: Improvement
> Components: Scripting
> Reporter: Joel Richard
> Priority: Minor
> Labels: performance
>
> Surprisingly, java.io.PrintWriter is relatively expensive to initialise
> because of the AccessController.doPrivileged call in the constructor. Right
> now, it initialises for each include a new PrintWriter which costs 2-3%
> rendering time.
> In order to avoid this overhead, I would suggest to fix SLING-1284 properly
> (as far as I have seen there is a real fix in Tomcat) and create a reusable
> PrintWriter in PageContextImpl together with the JspWriter. In addition, the
> OnDemandWriterResponse must be adjusted to not create a new PrintWriter.
> Maybe, all the OnDemand* classes could also just be removed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)