[
https://issues.apache.org/jira/browse/WICKET-6774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18111721#comment-18111721
]
ASF subversion and git services commented on WICKET-6774:
---------------------------------------------------------
Commit 338720c7fc3390a4746239ed1f31e65ca0f49e36 in wicket's branch
refs/heads/wicket-6774 from Emond Papegaaij
[ https://gitbox.apache.org/repos/asf?p=wicket.git;h=338720c7fc ]
WICKET-6774: benchmark a real ajax behavior, and hand out behavior ids first
Every behavior shape so far used AttributeModifier, which never needs a stable
id, so none of them created the BehaviorIdList that stores those ids. That is
the structure this issue claims its largest saving on, and it was the one case
the benchmarks did not cover. AJAX_BEHAVIOR adds a real AjaxEventBehavior, so
the numbers are comparable to the -36.2% serialized saving reported on the
issue in 2020; measured now it is -39.8% for the tree, -72 bytes of retained
heap and -32 bytes serialized per component.
Keeping STABLE_ID_BEHAVIOR alongside it is deliberate. The absolute saving is
the same for both, because the same structure is removed either way, but the
bare behavior carries almost nothing of its own and so reports -86% per
component against the real behavior's -68%. Having both makes it obvious that
the absolute figure is the one that carries over between cases and the
percentage is not.
readBehaviorById could not run at all before this. It looked up an id that was
never handed out, which the array index of the reworked state resolves happily
while master throws InvalidBehaviorIdException, since master only builds its
BehaviorIdList when getBehaviorId is called. The setup now assigns ids first,
the way rendering does, so the benchmark measures the same work on both.
With that fixed, the ajax paths measure (2 forks, ns/op, master -> reworked
state):
readBehaviorById 2.82 -> 1.62 -43%
readBehaviors[AJAX_BEHAVIOR] 11.15 -> 1.97 -82%, 72 -> 24 B/op
readMetaData[AJAX_BEHAVIOR] 1.06 -> 0.81 -24%
buildAndDetach[AJAX_BEHAVIOR] 51.59 -> 29.36 -43%, 180 -> 96 B/op
Meta data reads get cheaper as a side effect: master keeps the id list in the
component's own meta data, so any meta data read on a link or ajax component
pays to walk past it.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
> 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: Minor
> Attachments: ComponentBenchmarks.java, ComponentBenchmarks.java,
> 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.20.10#820010)
