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

Reply via email to