[
https://issues.apache.org/jira/browse/WICKET-6774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17096591#comment-17096591
]
Emond Papegaaij commented on WICKET-6774:
-----------------------------------------
[~thomas.heigl] I've identified and fixed a problem: State objects were
recreated over and over again when this was not needed. This is fixed now. Can
you run your tests again? Also, it would be very helpful if you could add your
tests to the code. We should expand the tests to cover more use cases,
components are used for more things than detaching :) Ideally the test should
cover the entire lifecycle of a component: instantiation, modification,
rendering, detaching. Perhaps we should use a more realistic scenario with a
full page with several different components (links, labels, a form with fields,
etc) and rendering that with WicketTester.
Finally, I'm having trouble running the tests from Eclipse. m2e is not running
the annotation processor. Do you know how to fix that?
> 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: Major
>
> 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)
