[
https://issues.apache.org/jira/browse/WICKET-6774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18111717#comment-18111717
]
ASF subversion and git services commented on WICKET-6774:
---------------------------------------------------------
Commit b50ba07902e3873f1bd64378479a8611276a4020 in wicket's branch
refs/heads/wicket-6774 from Emond Papegaaij
[ https://gitbox.apache.org/repos/asf?p=wicket.git;h=b50ba07902 ]
WICKET-6774: use a single state class instead of one per combination
ComponentState had four subclasses, one for each combination of model,
behaviors and meta data that is worth wrapping. Every unpacking call site
therefore dispatched over four implementations of the same six accessors,
which is past the point where HotSpot stops inlining a virtual call. Reading
state is done all over the framework, and a real page interleaves components
of every shape, so those call sites go megamorphic in practice even though a
benchmark that feeds one shape at a time will not show it.
The specialised classes were not buying anything to offset that. Two and three
reference fields both occupy 24 bytes on a 64 bit VM with compressed oops, so
one class with three fields is the same size as any of the four it replaces.
Measured on a tree of 1000 components, retained heap is identical for every
state shape, and serialized form grows by about one byte per component for the
two-slot shapes, where the third field is written as a null.
A single final class also removes 235 lines, and pack() now holds in one place
the rule that used to be spread over twelve setters: a wrapper is only worth
allocating while more than one kind of state is present, otherwise the value
goes into Component.data directly.
Measured with wicket-benchmarks, reading state over an array holding every
shape at once, 2 forks, ns/op:
readBehaviorsMixedShapes 31.50 -> 21.35 -32%
readMetaDataMixedShapes 25.27 -> 17.66 -30%
readModelMixedShapes 30.17 -> 21.28 -30%
Single-shape reads and allocation per operation are unchanged, as expected:
those call sites were already monomorphic, so this only affects dispatch.
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)
