[
https://issues.apache.org/jira/browse/WICKET-6771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17093156#comment-17093156
]
Thomas Heigl commented on WICKET-6771:
--------------------------------------
Here is the PR with my benchmark: [https://github.com/apache/wicket/pull/420]
Please run the benchmark 2-3 times to verify my results.
> Performance issues accessing component metadata
> -----------------------------------------------
>
> Key: WICKET-6771
> URL: https://issues.apache.org/jira/browse/WICKET-6771
> Project: Wicket
> Issue Type: Bug
> Components: wicket-core
> Affects Versions: 8.7.0, 9.0.0-M5
> Reporter: Thomas Heigl
> Priority: Major
> Attachments: image-2020-04-27-09-57-20-368.png
>
>
> We have recently rolled out continuous profiling using JFR to our production
> environment. With some very surprising results. The biggest one being that
> one of the hottest methods in our application is {{Component.getMetaData():}}
> !image-2020-04-27-09-57-20-368.png|width=1143,height=745!
> Component metadata is used to store removal operations for the duration of
> the request and is accessed every time a component's children are iterated
> and when detaching components.
> The profiler screenshot above shows one of the possible code paths.
> I couldn't believe this at first so I decided to write a JMH benchmark. It
> turns out that between 20% and 35% of time in the detach method is spent on
> getting (empty) removal metadata.
> The benchmark compares checking metadata with a request-level boolean flag
> that is set when a component has removals:
> {quote}# Run complete. Total time: 00:02:44
> Benchmark Score Error Units
> ComponentBenchmarks.detachComponentWithFlags *12295,363* ± 71,343 ops/s
> ComponentBenchmarks.detachComponentWithMetaData *8855,321* ± 34,743 ops/s
> {quote}
> I will shortly create a PR with the benchmark so you can replicate these
> issues.
> I have not found time yet to profile the metadata code to get to the root
> cause of this. Help would be greatly appreciated. If we cannot improve the
> performance of accessing metadata, I'd suggest introducing request-level
> flags that are checked before accessing metadata for the most active code
> paths like I have done in the benchmark.
> I will create separate tickets for some other issues found by profiling on
> production that are quite easy to fix. This issue is the most important
> finding though.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
