[jira] [Resolved] (WICKET-6771) Performance issues accessing component metadata while iterating

["Sven Meier (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/WICKET-6771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Sven Meier resolved WICKET-6771.
--------------------------------
    Fix Version/s: 8.9.0
                   9.0.0-M6
       Resolution: Fixed

MetaData is no longer accessed for iterating children, when no modification has happened

> Performance issues accessing component metadata while iterating
> ---------------------------------------------------------------
>
>                 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
>             Fix For: 9.0.0-M6, 8.9.0
>
>         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)