[
https://issues.apache.org/jira/browse/WICKET-6774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18111718#comment-18111718
]
ASF subversion and git services commented on WICKET-6774:
---------------------------------------------------------
Commit 44e5809d592858ab9c06f66cbecc2dffc9bef2bd in wicket's branch
refs/heads/wicket-6774 from Emond Papegaaij
[ https://gitbox.apache.org/repos/asf?p=wicket.git;h=44e5809d59 ]
WICKET-6774: check FLAG_MODEL_SET before unpacking the state
Reading a model went through the type check on Component.data first and only
then consulted the flag, so components without a model paid for the check
before being told there was nothing to find. Most components have no model at
all: of 548285 components measured on a production application, 61% have none.
Testing the flag first skips the check for those entirely. The flag is
authoritative, since it is set exactly when a model is stored, which is the
same order master uses in getModelImpl().
Measured with wicket-benchmarks over an array holding every state shape at
once, 2 forks, ns/op:
readModelMixedShapes 21.28 -> 16.54 -22%
which brings the total for this path to 30.17 -> 16.54, -45%, against 10.59
for master. The remainder is not explained by dispatch or by check order and
would need perfasm to attribute; at roughly 0.6ns per model read it is small
next to the gains on the other two accessors.
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)
