[jira] [Commented] (WICKET-6774) Separate model, behaviors and metadata into separate fields

["Emond Papegaaij (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/WICKET-6774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17095404#comment-17095404 ] 

Emond Papegaaij commented on WICKET-6774:
-----------------------------------------

I'm not a big fan of adding 2 additional fields to component. This might sound as a small trade-off, but you have to consider pages with thousands, if not millions of components. Currently, a component has 4 fields:
* id, a String, often a constant, which is interned, size = 4 (on 32 bit or with compressed oops)
* parent, a reference to another Component, size = 4
* generatedMarkupId, an int, size = 4
* data, an Object reference, size = 4

Splitting data into 3 fields, will increase the size of Component with 2 more fields of size 4, a 50% increase in size. Especially for applications with large pages with many simple components, this will be killing to memory usage and serialization overhead.

I do however agree that the way data is handled is not very clean. What about rewriting this whole part to use an interface with multiple implementations? data stores 3 kinds of objects: 0 or 1 model, 0, 1 or more medata entries and 0, 1 or more behaviors. This gives 2 * 3 * 3 = 18 implementations of this interface. In many cases, these will even be smaller than the current data-array. Also, the code will be a lot cleaner. However, I cannot guarantee that it will be faster. The dynamic dispatch to the interface implementation might give more overhead than the array search, but this hard to predict (as is often the case with micro-optimizations). The good thing is that this will not break the API, because this is all internal API.

> 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)