[ 
https://issues.apache.org/jira/browse/WICKET-6774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18111858#comment-18111858
 ] 

ASF subversion and git services commented on WICKET-6774:
---------------------------------------------------------

Commit 234ff1c36a51f6acc41b9371be7d3288e5b7ea0c in wicket's branch 
refs/heads/wicket-6774 from Emond Papegaaij
[ https://gitbox.apache.org/repos/asf?p=wicket.git;h=234ff1c36a ]

WICKET-6774: do not store a model that lazy initialisation did not find

getDefaultModel() memoises the inherited model lookup: when a component has no
model of its own, initModel() walks the parent chain for an
IComponentInheritedModel and, on a hit, allocates a wrapper bound to this
component, which setModelImpl() then stores so the next call is cheap. The
matching invalidation lives in detach().

It also stored the misses, and storing a miss records nothing, because the null
leaves FLAG_MODEL_SET clear and the next call walks the hierarchy again anyway.
So the write bought nothing while costing two field stores, to data and to
flags, on every call for a component without a model. Most components have
none: of 548285 components measured on a production application, 61% carry no
model. Master pays nothing here only incidentally, its setModelImpl() falling
through both branches when the flag is clear.

Skipping the call is a no-op by construction. FLAG_MODEL_SET is set exactly
when a non-null model was stored, and only setModelImpl() writes the model
slot, so getModelImpl() returning null implies the flag is clear; with the flag
clear ComponentState.setModel(null, data, false) returns data unchanged down
every branch and the setFlag() is already false. Nothing overrides
setModelImpl() or getModelImpl(), and initModel() raises
FLAG_INHERITABLE_MODEL only on the path that returns non-null.

Measured with wicket-benchmarks, reading models over an array of components,
harness overhead subtracted, ns per component:

                        master   before    after
    model present        1.117    0.871    0.889
    model absent         0.316    1.399    0.352
    mixed                0.654    1.197    0.340

The absent path was 4.4x master and is now level with it, and reading state
over interleaved components is faster than master rather than 83% slower.

Note that a miss is still not memoised, on master or here: every
getDefaultModel() on a component without a model re-walks its ancestors.
Fixing that needs somewhere to record that the lookup already failed.

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)

Reply via email to