[
https://issues.apache.org/jira/browse/WICKET-6774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17100195#comment-17100195
]
Emond Papegaaij commented on WICKET-6774:
-----------------------------------------
I've done some measurements in our application and counted all components on
all pages in our test suite. The count is done on detach and counted 548285
components in 2635 pages. In our application, none of the components combine
multiple behaviors with multiple meta data entries. Multiple meta data entries
seems to be very rare: only 1 in 15 pages has such a component.
|| ||0||1||>1||
|Models|336119|212166|
|Behaviors|356321|145797|46167|
|Metadata|504045|44067|173|
Unfortunately I cannot compare the sizes of the pages before and after these
changes in a representative way. The tests annotate many components with up to
3 {{AttributeModifier}}s to render additional information in the markup, used
by the selenium tests to identify and operate the components. I've adjusted the
counts above for these added behaviors, but this is not feasible for the
serialization size.
> 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
> Attachments: 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)
