[
https://issues.apache.org/jira/browse/WICKET-6774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17117795#comment-17117795
]
Emond Papegaaij commented on WICKET-6774:
-----------------------------------------
[~mgrigorov] Good questions, we did not yet get any complaints specific to
BehaviorIdList, but we all know that the size of pages matters. At Topicus we
often have issues with this and it interferes with replication. I've posted
some numbers before
(https://issues.apache.org/jira/browse/WICKET-6774?focusedCommentId=17099335&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17099335)
about the reduction in size of specific components, and getting rid of
BehaviorIdList saves about 36% in this case. Reduction is small in most other
cases, but typical components are identical in size or about 4% smaller.
Unfortunately, I don't have a good way of comparing the sizes in a reliable way
for a great number of pages in our tests. Our tests add a large number of
artificial AttributeModifiers, which disrupts the measurement.
> 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, 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)
