[
https://issues.apache.org/jira/browse/WICKET-1862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martijn Dashorst closed WICKET-1862.
------------------------------------
Resolution: Won't Fix
3x32 bits times all components that are alive in your server. This is
definitely a huge win for memory footprint. Imagine millions of components on
your server. I know: our app has such a footprint—currently (at a very low
usage time) we have 362163 Labels in memory. This can easily run into the
millions. Any memory *not* used by Wicket can be used by additional request
processing or caching of entity objects.
> 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.
