Thomas Heigl created WICKET-7041:
------------------------------------

             Summary: Reduce allocations when rendering component headers
                 Key: WICKET-7041
                 URL: https://issues.apache.org/jira/browse/WICKET-7041
             Project: Wicket
          Issue Type: Improvement
          Components: wicket-core
    Affects Versions: 9.12.0
            Reporter: Thomas Heigl
            Assignee: Thomas Heigl
         Attachments: image-2023-04-10-16-56-52-061.png

We noticed a *very* substantial amount of allocations coming from 
Component#internalRenderHead:

!image-2023-04-10-16-56-52-061.png|width=716,height=612!

This is the relevant part of the code:

https://github.com/apache/wicket/blame/9b4c5fe9a26174a06d612837297eca90ef8711cc/wicket-core/src/main/java/org/apache/wicket/Component.java#L2642

{code:java}
StringResponse markupHeaderResponse = new StringResponse();
Response oldResponse = getResponse();
RequestCycle.get().setResponse(markupHeaderResponse);
try
{
        // Make sure the markup source strategy contributes to the header first
        // to be backward compatible. WICKET-3761
        getMarkupSourcingStrategy().renderHead(this, container);
        CharSequence headerContribution = markupHeaderResponse.getBuffer();
        if (Strings.isEmpty(headerContribution) == false)
        {
                response.render(StringHeaderItem.forString(headerContribution));
        }
}
finally
{
        RequestCycle.get().setResponse(oldResponse);
}
{code}

The code *always* allocates a new StringResponse for rendering potential markup 
header contributions. Internally, this creates a new AppendingStringBuffer with 
capacity 128.

In my application, we do not use <wicket:head> tags at all. So 99.9% of these 
allocations are completely unnecessary.

Ideally, I'd like to get rid of the temporary StringResponse, but I don't know 
if thats possible without breaking things.

Another solution would be to create a LazyStringResponse that initializes the 
internal String buffer on first use.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to