[
https://issues.apache.org/jira/browse/WICKET-7046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17712785#comment-17712785
]
ASF GitHub Bot commented on WICKET-7046:
----------------------------------------
theigl opened a new pull request, #578:
URL: https://github.com/apache/wicket/pull/578
We currently buffer ajax responses twice, first wrapping them in a
`StringResponse` and then in an `AppendingStringBuffer`. This whole wrapping is
really only necessary when the application has one or more `IResponseFilter`.
By default, Wicket applications running in deployment mode *do not have* any
response filters.
This PR adjusts `AjaxRequestHandler#respond` to write the page update
directly to the response if no filters are active. This should drastically
reduce allocations for large ajax responses.
https://issues.apache.org/jira/browse/WICKET-7046
> Avoid allocating StringResponse when no response filters are active
> -------------------------------------------------------------------
>
> Key: WICKET-7046
> URL: https://issues.apache.org/jira/browse/WICKET-7046
> Project: Wicket
> Issue Type: Improvement
> Components: wicket-core
> Affects Versions: 9.12.0
> Reporter: Thomas Heigl
> Assignee: Thomas Heigl
> Priority: Major
>
> AjaxRequestHandler#respond currently always allocates a new StringResponse:
> {code:java}
> final StringResponse bodyResponse = new StringResponse();
> update.writeTo(bodyResponse, encoding);
> CharSequence filteredResponse = invokeResponseFilters(bodyResponse);
> response.write(filteredResponse);
> {code}
> Wrapping the response in a StringResponse is necessary for applying
> ResponseFilters that potentially modify the response.
> The thing is this: By default, a Wicket application running in deployment
> mode, does *not* have any response filters active. So in that case, we can
> avoid all of this expensive buffering.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
