[
https://issues.apache.org/jira/browse/WICKET-6771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17095332#comment-17095332
]
Thomas Heigl edited comment on WICKET-6771 at 4/29/20, 10:57 AM:
-----------------------------------------------------------------
Hi Sven!
I just ran the benchmark a couple of times with your changes:
{quote}
Benchmark Score Error Units
ComponentBenchmarks.detachComponentWithMetaData *11304,774* ± 742,698 ops/s
{quote}
It is faster than the original code but it is slower than my flag demo because
metadata is still accessed for every detaching component in
{{MarkupContainer.onDetach}} by {{removals_clear}} and by
{{Component.detachFeedback}}.
And it is much slower than the version with metadata extracted into a separate
field.
So I'd say your change is good and will likely improve the situation
significantly, but there still is much room for improvement.
Should I modify my PR to only include the changes to extract metadata and model
into separate fields, so we can discuss the implications? Or is this a change
you would not consider making?
was (Author: thomas.heigl):
Hi Sven!
I just ran the benchmark a couple of times with your changes:
{quote}
Benchmark Score Error Units
ComponentBenchmarks.detachComponentWithMetaData *11304,774* ± 742,698 ops/s
{quote}
It is faster than the original code but it is slower than my flag demo because
metadata is still accessed for every detaching component in {{onDetach}} by
{{removals_clear}}.
And it is much slower than the version with metadata extracted into a separate
field.
So I'd say your change is good and will likely improve the situation
significantly, but there still is much room for improvement.
Should I modify my PR to only include the changes to extract metadata and model
into separate fields, so we can discuss the implications? Or is this a change
you would not consider making?
> 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)
