[ https://issues.apache.org/jira/browse/WICKET-6774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17099335#comment-17099335 ]
Emond Papegaaij edited comment on WICKET-6774 at 5/4/20, 8:29 PM: ------------------------------------------------------------------ The problem with a single flag for all metadata is that it is difficult to clear the flag. Every call to {{setMetaData}} would have to check the metadata to see if the flag needs to be cleared. I've opened a new ticket for the REMOVALS_KEY: WICKET-6778. Still, even with the flag, I would like to continue with this branch. I've done some measurements in serialization size, and the results are very promising: {code} Plain component: 105716 -> 105716 (identical) Component with model: 131607 -> 131607 (identical) Component with simple behavior: 158455 -> 158455 (identical) Component with model and simple behavior: 211802 -> 201920 (-4.7%) Component with metadata: 163856 -> 163856 (identical) Component with model and metadata: 217827 -> 207774 (-4.6%) Component with simple behavior and metadata: 244125 -> 234250 (-4.0%) Component with model, simple behavior and metadata: 272992 -> 263039 (-3.6%) Component with ajax behavior: 226053 -> 144329 (-36.2%) Component with 2 simple behaviors and 2 metadata-entries: 395546 -> 410538 (+3.8%) {code} Only the cases where multiple behaviors are combined with a model or metadata are larger. It may be possible to improve on this by adding specialized classes for 2 and maybe 3 behaviors. But this will come at a computational and code complexity cost. was (Author: papegaaij): The problem with a single flag for all metadata is that it is difficult to clear the flag. Every call to {{setMetaData}} would have to check the metadata to see if the flag needs to be cleared. I've opened a new ticket for the REMOVALS_KEY: WICKET-6778. Still, even with the flag, I would like to continue with this branch. I've done some measurements in serialization size, and the results are very promising: {{code}} Plain component: 105716 -> 105716 (identical) Component with model: 131607 -> 131607 (identical) Component with simple behavior: 158455 -> 158455 (identical) Component with model and simple behavior: 211802 -> 201920 (-4.7%) Component with metadata: 163856 -> 163856 (identical) Component with model and metadata: 217827 -> 207774 (-4.6%) Component with simple behavior and metadata: 244125 -> 234250 (-4.0%) Component with model, simple behavior and metadata: 272992 -> 263039 (-3.6%) Component with ajax behavior: 226053 -> 144329 (-36.2%) Component with 2 simple behaviors and 2 metadata-entries: 395546 -> 410538 (+3.8%) {{code}} Only the cases where multiple behaviors are combined with a model or metadata are larger. It may be possible to improve on this by adding specialized classes for 2 and maybe 3 behaviors. But this will come at a computational and code complexity cost. > 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 > Attachments: 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)