[
https://issues.apache.org/jira/browse/WICKET-1862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12637856#action_12637856
]
Willis Blackburn commented on WICKET-1862:
------------------------------------------
By the way, I'm not familiar with exactly how Wicket uses behaviors and
"metadata." But if an object just has an IModel instance, then I don't think
that the new strategy actually saves any memory at all. In fact, it probably
uses more memory. Component has:
reference-to-IModel (4 bytes) -> IModel
reference-to-Object (4 bytes) -> null
reference-to-MetaDataEntry[] (4 bytes) -> null
The new strategy has:
reference-to-Object[] (4 bytes) -> Object[1] (8 bytes overhead + 4 bytes for
the reference-to-Object) -> IModel
So looks like 12 bytes for the original implementation versus 16 bytes for the
new one, not counting any losses due to alignment.
> Please consider backing out changes to Component that merged dissimilar
> objects into an Object[]
> ------------------------------------------------------------------------------------------------
>
> Key: WICKET-1862
> URL: https://issues.apache.org/jira/browse/WICKET-1862
> Project: Wicket
> Issue Type: Improvement
> Components: wicket
> Affects Versions: 1.3.4
> Reporter: Willis Blackburn
> Priority: Minor
>
> In Wicket 1.2, the members of the Component class were pretty straightforward.
> But in 1.3, three fields, including the model, have been merged into a single
> Object[], and there are new methods called data_get, data_set, data_length,
> data_add, data_remove, and data_insert, to deal with the array.
> I cannot determine from the source code why this was done, but it does not
> seem like a change for the better. The Component class is now very
> confusing, and the change has also made working with any Component subclass
> (in other words, practically every Wicket class!) in the debugger more
> difficult. I think that when three fields that used to be accessed in a
> simple and straightforward manner are replaced by 160 lines of code, there
> needs to be some very compelling reason.
> Maybe the motivation was to reduce the memory footprint of a Component
> instance that does not have any model, behaviors, or metadata, or maybe one
> that just has one of the three? If so, is that really so compelling? Is the
> memory footprint that large? Are users suffering from problems that have
> been addressed by this solution? In the context of the memory usage of a
> typical webapp, saving something like 8 bytes per Component instance does not
> seem like that much.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
