[ https://issues.apache.org/jira/browse/WICKET-6771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17095348#comment-17095348 ]
Sven Meier commented on WICKET-6771: ------------------------------------ Hi Thomas, let's keep this issue for optimizing iteration of children, i.e. metadata is no longer accessed for each iterated child. I will apply the optimization to 8.x too. Please open a new issue for separating metadata, model and behaviors in separate fields. We'll have to discuss this, maybe it is something to consider for 9.x. Thanks Sven > 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 > Assignee: Sven Meier > 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)