[
https://issues.apache.org/jira/browse/WICKET-6774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17116867#comment-17116867
]
Thomas Heigl commented on WICKET-6774:
--------------------------------------
Hi [~papegaaij]. I ran your benchmark and it seems to be as fast or faster than
master for all current test cases.
I like the approach of encapsulating the different variations of state in
separate objects and it reads very well. However, your PR adds more than 500
lines of code that are in no way trivial. Especially the various transitions
between states are difficult to wrap your head around. I'm not really sure if
the 5-10% performance gains are worth adding that much code that has to be
maintained in the future. This is just my gut feeling though and I'd like to
hear other opinions.
As you pointed out some time ago, our benchmarks currently only test the detach
phase. I'm planning to write a more comprehensive benchmark suite that actually
renders the components and can be used for future refactorings as well. I'm
interested to see how your rework performs in more realistic scenarios.
> Separate model, behaviors and metadata into separate fields
> -----------------------------------------------------------
>
> Key: WICKET-6774
> URL: https://issues.apache.org/jira/browse/WICKET-6774
> Project: Wicket
> Issue Type: Improvement
> Components: wicket-core
> Affects Versions: 9.0.0-M5
> Reporter: Thomas Heigl
> Priority: Minor
> Attachments: ComponentBenchmarks.java, benchmarks.png
>
>
> While investigating performance issues with metadata in WICKET-6771, I
> discovered that significant performance gains can be achieved by separating
> models, behaviors, and metadata into separate fields.
> Currently, all three types of data are stored in a single, untyped field
> {{Component.data}}. The idea is to minimize memory overhead by creating as
> few objects as possible.
> If a model or a single behavior or metadata is added, {{data}} stores only a
> reference to the object. When additional data is added, the reference becomes
> an array.
> This is the most memory-efficient way to store these three types of data. But
> it comes with a cost: code to manipulate that data structure is complex and
> not as efficient because it has to take all possible combinations of data
> into account.
> I suggest introducing 3 separate fields for the 3 types of data, trading a
> little bit of memory for reduced complexity and performance gains.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
