[
https://issues.apache.org/jira/browse/WICKET-6774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17095510#comment-17095510
]
Emond Papegaaij commented on WICKET-6774:
-----------------------------------------
[~thomas.heigl] thank you for bringing all this up. Discussions like these are
what drives the development of Wicket.
I just gave my own suggestion a bit more thought, and I made an error in my
judgement. When storing just one object (model, metadata or behavior), the
overhead of creating a storage implementation is substantial. I think we should
give the following implementation a try:
* nothing -> store singleton {{NoComponentState}}
* just a model, metadata or behavior -> store it in data
* all other cases -> create an implementation of the {{IComponentState}}
interface and store that in data
Implementation of {{getModelImpl}} will look like:
{code}
if (data instanceof IModel)
return (IModel<?>) data;
return ((IComponentState) data).getModel();
{code}
Maybe storing {{null}} instead of a singleton is faster, but that would
introduce a null check in several places. We should benchmark the difference I
guess. The operations to set the data will be a bit more involved, especially
because of the 3 special cases.
I may be able to give this implementation a try somewhere this week, but
unfortunately my time is somewhat limited at the moment due to a very high
workload on my primary project, so I cannot make any promises.
> 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)