[
https://issues.apache.org/jira/browse/WICKET-6774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18111709#comment-18111709
]
ASF subversion and git services commented on WICKET-6774:
---------------------------------------------------------
Commit 36626baf20bb26069e4f52395d38e9c04a62d60a in wicket's branch
refs/heads/wicket-6774 from Emond Papegaaij
[ https://gitbox.apache.org/repos/asf?p=wicket.git;h=36626baf20 ]
WICKET-6774: add wicket-benchmarks module
The component benchmarks used to investigate this issue only ever existed as
attachments on WICKET-6774, and they no longer compile: WicketTester has moved
to its own module, and since JDK 23 javac no longer runs annotation processors
found on the classpath, so JMH silently produces no BenchmarkList and the run
executes nothing. Keeping them in the reactor means they keep compiling.
Three tools, because the constraints they check are not the same question:
* ComponentStateBenchmark - JMH, ns/op and bytes/op for the per-request state
accessors. Reads are measured per state shape and again over a component
array holding every shape at once. With a single shape the call sites that
unpack Component.data are monomorphic and inline, which flatters any
implementation dispatching on the shape, while real pages interleave shapes.
Mutation is measured as construct-and-detach in one operation, because
detach() is not idempotent and so cannot be measured repeatedly against the
same instance.
* ComponentFootprint - retained heap via JOL and serialized size via Java
serialization, per shape, against an identical stateless tree so that the
difference isolates the state itself. Neither is a throughput question, and
a footprint claim also depends on -XX:+UseCompactObjectHeaders, which can
change which layout wins.
* PageRenderBenchmark - a full render as an end-to-end regression guard. The
seven near-identical methods of the original are replaced by one
parameterised over the state shape.
The shapes include a behavior that requires a stable id, which is what every
link and ajax-enabled component has, and which the original benchmarks never
covered even though the largest saving claimed on this issue is there.
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)
