[jira] [Commented] (WICKET-6774) Separate model, behaviors and metadata into separate fields
[
https://issues.apache.org/jira/browse/WICKET-6774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17096938#comment-17096938
]
Emond Papegaaij commented on WICKET-6774:
-
These are my numbers with the fixed testcase:
{code}
WICKET-6774 branch:
Benchmark Mode Cnt
Score Error Units
ComponentBenchmarks.detachComponent thrpt 10
20057.391 ± 419.863 ops/s
ComponentBenchmarks.detachComponentWithBehavior thrpt 10
8915.848 ± 226.096 ops/s
ComponentBenchmarks.detachComponentWithBehaviorAndMetaData thrpt 10
7955.890 ± 103.236 ops/s
ComponentBenchmarks.detachComponentWithMetaData thrpt 10
17444.035 ± 207.528 ops/s
ComponentBenchmarks.detachComponentWithModel thrpt 10
7289.186 ± 101.425 ops/s
ComponentBenchmarks.detachComponentWithModelAndBehavior thrpt 10
4159.578 ± 56.863 ops/s
ComponentBenchmarks.detachComponentWithModelAndMetaData thrpt 10
4466.525 ± 101.193 ops/s
ComponentBenchmarks.detachComponentWithModelBehaviorAndMetaData thrpt 10
3460.594 ± 132.584 ops/s
master:
Benchmark Mode Cnt
Score Error Units
ComponentBenchmarks.detachComponent thrpt 10
12905.077 ± 273.182 ops/s
ComponentBenchmarks.detachComponentWithBehavior thrpt 10
6632.926 ± 109.922 ops/s
ComponentBenchmarks.detachComponentWithBehaviorAndMetaData thrpt 10
6448.901 ± 106.836 ops/s
ComponentBenchmarks.detachComponentWithMetaData thrpt 10
12980.235 ± 188.695 ops/s
ComponentBenchmarks.detachComponentWithModel thrpt 10
6660.698 ± 56.481 ops/s
ComponentBenchmarks.detachComponentWithModelAndBehavior thrpt 10
3985.500 ± 54.724 ops/s
ComponentBenchmarks.detachComponentWithModelAndMetaData thrpt 10
5019.874 ± 74.391 ops/s
ComponentBenchmarks.detachComponentWithModelBehaviorAndMetaData thrpt 10
3813.014 ± 36.410 ops/s
{code}
> 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: Major
> Attachments: 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.3.4#803005)
[wicket] branch wicket-6774 updated: WICKET-6774: inline state unpacking to improve performance
This is an automated email from the ASF dual-hosted git repository.
papegaaij pushed a commit to branch wicket-6774
in repository https://gitbox.apache.org/repos/asf/wicket.git
The following commit(s) were added to refs/heads/wicket-6774 by this push:
new a354416 WICKET-6774: inline state unpacking to improve performance
a354416 is described below
commit a354416a0e95330aec948c4b98ba863bdc044af0
Author: Emond Papegaaij
AuthorDate: Thu Apr 30 21:43:21 2020 +0200
WICKET-6774: inline state unpacking to improve performance
---
.../java/org/apache/wicket/ComponentState.java | 152 +
1 file changed, 127 insertions(+), 25 deletions(-)
diff --git a/wicket-core/src/main/java/org/apache/wicket/ComponentState.java
b/wicket-core/src/main/java/org/apache/wicket/ComponentState.java
index f63d72b..94a81bd 100644
--- a/wicket-core/src/main/java/org/apache/wicket/ComponentState.java
+++ b/wicket-core/src/main/java/org/apache/wicket/ComponentState.java
@@ -1,18 +1,12 @@
/*
- * Licensed to the Apache Software Foundation (ASF) under one or more
- * contributor license agreements. See the NOTICE file distributed with
- * this work for additional information regarding copyright ownership.
- * The ASF licenses this file to You under the Apache License, Version 2.0
- * (the "License"); you may not use this file except in compliance with
- * the License. You may obtain a copy of the License at
- *
- * http://www.apache.org/licenses/LICENSE-2.0
- *
- * Unless required by applicable law or agreed to in writing, software
- * distributed under the License is distributed on an "AS IS" BASIS,
- * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- * See the License for the specific language governing permissions and
- * limitations under the License.
+ * Licensed to the Apache Software Foundation (ASF) under one or more
contributor license
+ * agreements. See the NOTICE file distributed with this work for additional
information regarding
+ * copyright ownership. The ASF licenses this file to You under the Apache
License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance with the
License. You may obtain a
+ * copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless
required by applicable
+ * law or agreed to in writing, software distributed under the License is
distributed on an "AS IS"
+ * BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
implied. See the License
+ * for the specific language governing permissions and limitations under the
License.
*/
package org.apache.wicket;
@@ -206,30 +200,137 @@ abstract class ComponentState implements Serializable
static Object setModel(IModel< ? > model, Object state, boolean
modelSet)
{
- return createState(state, model, getBehaviors(state, modelSet),
- getMetaData(state, modelSet));
+ Object stateBehavior;
+ Object stateMetaData;
+ if (state instanceof ComponentState)
+ {
+ ComponentState compState = (ComponentState) state;
+ stateBehavior = compState.getBehaviors();
+ stateMetaData = compState.getMetaData();
+ }
+ else if (modelSet)
+ {
+ stateBehavior = null;
+ stateMetaData = null;
+ }
+ else if (state instanceof MetaDataEntry || state instanceof
MetaDataEntry[])
+ {
+ stateBehavior = null;
+ stateMetaData = state;
+ }
+ else
+ {
+ stateBehavior = state;
+ stateMetaData = null;
+ }
+
+ return createState(state, model, stateBehavior, stateMetaData);
}
static Object addBehaviors(Component component, Object state, boolean
modelSet,
Behavior... behaviorsToAdd)
{
- return createState(state, getModel(state, modelSet),
- addBehaviors(component, getBehaviors(state, modelSet),
behaviorsToAdd),
- getMetaData(state, modelSet));
+ IModel< ? > stateModel;
+ Object stateBehavior;
+ Object stateMetaData;
+ if (state instanceof ComponentState)
+ {
+ ComponentState compState = (ComponentState) state;
+ stateModel = compState.getModel();
+ stateBehavior = compState.getBehaviors();
+ stateMetaData = compState.getMetaData();
+ }
+ else if (modelSet)
+ {
+ stateModel = (IModel< ? >) state;
+ stateBehavior = null;
+ stateMetaData = null;
[jira] [Commented] (WICKET-6774) Separate model, behaviors and metadata into separate fields
[
https://issues.apache.org/jira/browse/WICKET-6774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17096925#comment-17096925
]
ASF subversion and git services commented on WICKET-6774:
-
Commit a354416a0e95330aec948c4b98ba863bdc044af0 in wicket's branch
refs/heads/wicket-6774 from Emond Papegaaij
[ https://gitbox.apache.org/repos/asf?p=wicket.git;h=a354416 ]
WICKET-6774: inline state unpacking to improve performance
> 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: Major
> Attachments: 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.3.4#803005)
[jira] [Commented] (WICKET-6774) Separate model, behaviors and metadata into separate fields
[
https://issues.apache.org/jira/browse/WICKET-6774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17096888#comment-17096888
]
Emond Papegaaij commented on WICKET-6774:
-
We should be very careful with these micro benchmarks. Your numbers already
show a very interesting case: your testcase contains an error on component2. It
is constructed with the same parameters as component0, still the numbers are
way off. Either your actual testcase is somewhat different or the difference in
numbers has a whole different cause. It can be a difference in memory
allocation, but it can also be that your system is throttling down due to heat
or power consumption. Interestingly enough, I'm seeing similar numbers. I don't
have a good explanation.
More importantly, we are only testing detach. I'm not saying that detach
performance can be increased, but this case is very limited. During detach of
your testcase, {{setMetaData}} is called many times with data = null. This is
the only call to any of the state of the components. Therefore, it makes sense
that in this particular case performance is limited by this call, and
eliminating it will increase performance for this case. However, this is not a
typical application and the other elements of the state are accessed by other
parts of Wicket. Optimizing for this case may reduce performance for the other
(probably more important) cases.
That being said, I do think we should continue profiling and benchmarking
component state, but in a richer setup. I've continued to improve the
performance of my branch. For the detach case, I'd consider it on par with or
faster than master.
I think we should add the feedback flag. The setMetaData call per component is
a lot more expensive than a simple flag check. Not many components do have
feedback.
> 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: Major
> Attachments: 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.3.4#803005)
[jira] [Comment Edited] (WICKET-6774) Separate model, behaviors and metadata into separate fields
[
https://issues.apache.org/jira/browse/WICKET-6774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17096694#comment-17096694
]
Thomas Heigl edited comment on WICKET-6774 at 4/30/20, 4:05 PM:
I just ran all tests again and added a test against the master with added flags
for metadata and behaviors. Your branch is still slightly slower than the
master. And as expected, master with flags is the fastest:
!benchmarks.png|width=878,height=687!
was (Author: thomas.heigl):
I just ran all tests again and added a test against the master with added flags
for metadata and behaviors. Your branch is still slightly slower than the
master. And as expected, master with flags is the fastest:
!benchmarks.png|width=997,height=780!
> 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: Major
> Attachments: 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.3.4#803005)
[jira] [Comment Edited] (WICKET-6774) Separate model, behaviors and metadata into separate fields
[
https://issues.apache.org/jira/browse/WICKET-6774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17096694#comment-17096694
]
Thomas Heigl edited comment on WICKET-6774 at 4/30/20, 4:04 PM:
I just ran all tests again and added a test against the master with added flags
for metadata and behaviors. Your branch is still slightly slower than the
master. And as expected, master with flags is the fastest:
!benchmarks.png|width=997,height=780!
was (Author: thomas.heigl):
I just ran all tests again and added a test against the master with added flags
for metadata and behaviors. Your branch is still slightly slower than the
master. And as expected, master with flags is the fastest:
!benchmarks.png!
> 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: Major
> Attachments: 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.3.4#803005)
[jira] [Commented] (WICKET-6774) Separate model, behaviors and metadata into separate fields
[
https://issues.apache.org/jira/browse/WICKET-6774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17096694#comment-17096694
]
Thomas Heigl commented on WICKET-6774:
--
I just ran all tests again and added a test against the master with added flags
for metadata and behaviors. Your branch is still slightly slower than the
master. And as expected, master with flags is the fastest:
!benchmarks.png!
> 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: Major
> Attachments: 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.3.4#803005)
[jira] [Updated] (WICKET-6774) Separate model, behaviors and metadata into separate fields
[
https://issues.apache.org/jira/browse/WICKET-6774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Heigl updated WICKET-6774:
-
Attachment: benchmarks.png
> 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: Major
> Attachments: 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.3.4#803005)
[jira] [Commented] (WICKET-6774) Separate model, behaviors and metadata into separate fields
[
https://issues.apache.org/jira/browse/WICKET-6774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17096602#comment-17096602
]
Thomas Heigl commented on WICKET-6774:
--
These are the current tests:
https://gist.github.com/theigl/0fe8811f7f0ed964a5a1bbbc34fb0cd8
Please copy them to your branch.
I'm simply running the main method from IntelliJ without any additional
settings. Could you try to run it directly from the console?
> 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: Major
>
> 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.3.4#803005)
[jira] [Commented] (WICKET-6774) Separate model, behaviors and metadata into separate fields
[
https://issues.apache.org/jira/browse/WICKET-6774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17096591#comment-17096591
]
Emond Papegaaij commented on WICKET-6774:
-
[~thomas.heigl] I've identified and fixed a problem: State objects were
recreated over and over again when this was not needed. This is fixed now. Can
you run your tests again? Also, it would be very helpful if you could add your
tests to the code. We should expand the tests to cover more use cases,
components are used for more things than detaching :) Ideally the test should
cover the entire lifecycle of a component: instantiation, modification,
rendering, detaching. Perhaps we should use a more realistic scenario with a
full page with several different components (links, labels, a form with fields,
etc) and rendering that with WicketTester.
Finally, I'm having trouble running the tests from Eclipse. m2e is not running
the annotation processor. Do you know how to fix that?
> 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: Major
>
> 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.3.4#803005)
[jira] [Commented] (WICKET-6774) Separate model, behaviors and metadata into separate fields
[
https://issues.apache.org/jira/browse/WICKET-6774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17096585#comment-17096585
]
ASF subversion and git services commented on WICKET-6774:
-
Commit d091fe0d7cf4ba1d4889b1be3f151344a1dfac58 in wicket's branch
refs/heads/wicket-6774 from Emond Papegaaij
[ https://gitbox.apache.org/repos/asf?p=wicket.git;h=d091fe0 ]
WICKET-6774: do not recreate state when not needed
> 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: Major
>
> 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.3.4#803005)
[wicket] branch wicket-6774 updated: WICKET-6774: do not recreate state when not needed
This is an automated email from the ASF dual-hosted git repository.
papegaaij pushed a commit to branch wicket-6774
in repository https://gitbox.apache.org/repos/asf/wicket.git
The following commit(s) were added to refs/heads/wicket-6774 by this push:
new d091fe0 WICKET-6774: do not recreate state when not needed
d091fe0 is described below
commit d091fe0d7cf4ba1d4889b1be3f151344a1dfac58
Author: Emond Papegaaij
AuthorDate: Thu Apr 30 16:28:02 2020 +0200
WICKET-6774: do not recreate state when not needed
---
.../java/org/apache/wicket/ComponentState.java | 47 ++
1 file changed, 40 insertions(+), 7 deletions(-)
diff --git a/wicket-core/src/main/java/org/apache/wicket/ComponentState.java
b/wicket-core/src/main/java/org/apache/wicket/ComponentState.java
index 7795af7..f63d72b 100644
--- a/wicket-core/src/main/java/org/apache/wicket/ComponentState.java
+++ b/wicket-core/src/main/java/org/apache/wicket/ComponentState.java
@@ -206,13 +206,14 @@ abstract class ComponentState implements Serializable
static Object setModel(IModel< ? > model, Object state, boolean
modelSet)
{
- return createState(model, getBehaviors(state, modelSet),
getMetaData(state, modelSet));
+ return createState(state, model, getBehaviors(state, modelSet),
+ getMetaData(state, modelSet));
}
static Object addBehaviors(Component component, Object state, boolean
modelSet,
Behavior... behaviorsToAdd)
{
- return createState(getModel(state, modelSet),
+ return createState(state, getModel(state, modelSet),
addBehaviors(component, getBehaviors(state, modelSet),
behaviorsToAdd),
getMetaData(state, modelSet));
}
@@ -220,18 +221,19 @@ abstract class ComponentState implements Serializable
static Object removeBehaviors(Component component, Object state,
boolean modelSet,
Behavior... behaviorsToRemove)
{
- return createState(getModel(state, modelSet),
+ return createState(state, getModel(state, modelSet),
removeBehaviors(component, getBehaviors(state,
modelSet), behaviorsToRemove),
getMetaData(state, modelSet));
}
static Object setMetaData(Object state, boolean modelSet,
MetaDataKey key, T data)
{
- return createState(getModel(state, modelSet),
getBehaviors(state, modelSet),
+ return createState(state, getModel(state, modelSet),
getBehaviors(state, modelSet),
setMetaData(getMetaData(state, modelSet), key, data));
}
- private static Object createState(IModel< ? > model, Object behaviors,
Object metaData)
+ private static Object createState(Object oldState, IModel< ? > model,
Object behaviors,
+ Object metaData)
{
if (model == null)
{
@@ -254,6 +256,14 @@ abstract class ComponentState implements Serializable
}
else
{
+ if (oldState instanceof
BehaviorsMetaDataComponentState)
+ {
+ BehaviorsMetaDataComponentState
old =
+
(BehaviorsMetaDataComponentState) oldState;
+ old.behaviors = behaviors;
+ old.metaData = metaData;
+ return old;
+ }
return new
BehaviorsMetaDataComponentState(behaviors, metaData);
}
}
@@ -268,6 +278,13 @@ abstract class ComponentState implements Serializable
}
else
{
+ if (oldState instanceof
ModelMetaDataComponentState)
+ {
+ ModelMetaDataComponentState old
= (ModelMetaDataComponentState) oldState;
+ old.model = model;
+ old.metaData = metaData;
+ return old;
+ }
return new
ModelMetaDataComponentState(model, metaData);
}
}
@@ -275,10 +292,26 @@ abstract class ComponentState implements Serializable
{
if (metaData == null)
[jira] [Commented] (WICKET-6774) Separate model, behaviors and metadata into separate fields
[
https://issues.apache.org/jira/browse/WICKET-6774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17096515#comment-17096515
]
Thomas Heigl commented on WICKET-6774:
--
Results are the same. Your branch is only faster in the case where only
metadata is set. In the other cases it is slightly slower.
> 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: Major
>
> 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.3.4#803005)
[jira] [Commented] (WICKET-6774) Separate model, behaviors and metadata into separate fields
[
https://issues.apache.org/jira/browse/WICKET-6774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17096499#comment-17096499
]
Thomas Heigl commented on WICKET-6774:
--
I will add some more tests for the most common cases: model only, behavior
only, and model and behavior.
> 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: Major
>
> 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.3.4#803005)
[jira] [Commented] (WICKET-6774) Separate model, behaviors and metadata into separate fields
[
https://issues.apache.org/jira/browse/WICKET-6774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17096498#comment-17096498
]
Thomas Heigl commented on WICKET-6774:
--
[~papegaaij]: I extended my benchmark and ran it against your branch and the
master. Your branch is significantly faster for the case with only metadata,
but slightly slower for the other cases.
Master:
||Benchmark || Mode ||
Cnt || Score || Error || Units||
|ComponentBenchmarks.detachComponent | thrpt | 20
| 15528,367 |± 32,690 | ops/s|
|ComponentBenchmarks.detachComponentWithMetaData |thrpt | 20
|10236,115 |± 95,023 | ops/s|
|ComponentBenchmarks.detachComponentWithMetaDataAndModel | thrpt | 20
| 4139,486 |± 7,065| ops/s|
|ComponentBenchmarks.detachComponentWithMetaDataModelAndBehavior | thrpt | 20
| 3260,999 | ± 21,927 | ops/s|
Your branch:
||Benchmark || Mode ||
Cnt || Score || Error ||Units||
|ComponentBenchmarks.detachComponent | thrpt |
20| 14142,217 | ± 786,319 | ops/s|
|ComponentBenchmarks.detachComponentWithMetaData |thrpt |
20 | 13448,754 | ± 75,604 | ops/s|
|ComponentBenchmarks.detachComponentWithMetaDataAndModel| thrpt|
20|3292,400| ± 11,846 | ops/s|
|ComponentBenchmarks.detachComponentWithMetaDataModelAndBehavior | thrpt |
20 | 2644,336| ± 10,262| ops/s|
I guess the only way to further improve the performance without changing the
data structure is to add flags for {{METADATA_SET}} and {{BEHAVIOR_SET}} and
return early if these are not set.
> 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: Major
>
> 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.3.4#803005)
[jira] [Commented] (WICKET-6774) Separate model, behaviors and metadata into separate fields
[
https://issues.apache.org/jira/browse/WICKET-6774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17096453#comment-17096453
]
Emond Papegaaij commented on WICKET-6774:
-
[~thomas.heigl] I would really appreciate it if you could take a look at my
pull request: https://github.com/apache/wicket/pull/424 . Is this
implementation more efficient than the old one?
> 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: Major
>
> 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.3.4#803005)
[jira] [Commented] (WICKET-6774) Separate model, behaviors and metadata into separate fields
[
https://issues.apache.org/jira/browse/WICKET-6774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17096450#comment-17096450
]
ASF subversion and git services commented on WICKET-6774:
-
Commit bdf47068e9e671037954263f76935f5a3455e609 in wicket's branch
refs/heads/wicket-6774 from Emond Papegaaij
[ https://gitbox.apache.org/repos/asf?p=wicket.git;h=bdf4706 ]
WICKET-6774: rework of component state
State of a component is no longer stored as an array but using instances
of ComponentState. These have a smaller memory footprint in most cases,
are more efficient and the code is easier to read (I hope).
Note that a small change in behavior is introduced: behavior ids are
only maintained for statefull behaviors. Ids can change for other
behaviors, also when combined on the same component.
> 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: Major
>
> 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.3.4#803005)
[wicket] 01/01: WICKET-6774: rework of component state
This is an automated email from the ASF dual-hosted git repository.
papegaaij pushed a commit to branch wicket-6774
in repository https://gitbox.apache.org/repos/asf/wicket.git
commit bdf47068e9e671037954263f76935f5a3455e609
Author: Emond Papegaaij
AuthorDate: Thu Apr 30 13:40:45 2020 +0200
WICKET-6774: rework of component state
State of a component is no longer stored as an array but using instances
of ComponentState. These have a smaller memory footprint in most cases,
are more efficient and the code is easier to read (I hope).
Note that a small change in behavior is introduced: behavior ids are
only maintained for statefull behaviors. Ids can change for other
behaviors, also when combined on the same component.
---
.../src/main/java/org/apache/wicket/Behaviors.java | 325 --
.../src/main/java/org/apache/wicket/Component.java | 284 +---
.../java/org/apache/wicket/ComponentState.java | 714 +
.../wicket/core/util/lang/WicketObjects.java | 1 +
.../wicket/behavior/ImmutableBehaviorIdsTest.java | 26 +-
.../html/basic/SimplePageExpectedResult_13.html| 2 +-
6 files changed, 759 insertions(+), 593 deletions(-)
diff --git a/wicket-core/src/main/java/org/apache/wicket/Behaviors.java
b/wicket-core/src/main/java/org/apache/wicket/Behaviors.java
deleted file mode 100644
index aceb318..000
--- a/wicket-core/src/main/java/org/apache/wicket/Behaviors.java
+++ /dev/null
@@ -1,325 +0,0 @@
-/*
- * Licensed to the Apache Software Foundation (ASF) under one or more
- * contributor license agreements. See the NOTICE file distributed with
- * this work for additional information regarding copyright ownership.
- * The ASF licenses this file to You under the Apache License, Version 2.0
- * (the "License"); you may not use this file except in compliance with
- * the License. You may obtain a copy of the License at
- *
- * http://www.apache.org/licenses/LICENSE-2.0
- *
- * Unless required by applicable law or agreed to in writing, software
- * distributed under the License is distributed on an "AS IS" BASIS,
- * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- * See the License for the specific language governing permissions and
- * limitations under the License.
- */
-package org.apache.wicket;
-
-import java.util.ArrayList;
-import java.util.Collections;
-import java.util.List;
-
-import org.apache.wicket.behavior.Behavior;
-import org.apache.wicket.behavior.InvalidBehaviorIdException;
-import org.apache.wicket.model.IDetachable;
-import org.apache.wicket.util.lang.Args;
-
-/**
- * Manages behaviors in a {@link Component} instance
- *
- * @author igor
- */
-final class Behaviors implements IDetachable
-{
- private static final long serialVersionUID = 1L;
- private final Component component;
-
- public Behaviors(Component component)
- {
- this.component = component;
- }
-
- public void add(Behavior... behaviors)
- {
- Args.notNull(behaviors, "behaviors");
-
- for (Behavior behavior : behaviors)
- {
- Args.notNull(behavior, "behavior");
-
- internalAdd(behavior);
-
- if (!behavior.isTemporary(component))
- {
- component.addStateChange();
- }
-
- // Give handler the opportunity to bind this component
- behavior.bind(component);
- }
- }
-
- private void internalAdd(final Behavior behavior)
- {
- component.data_add(behavior);
- if (behavior.getStatelessHint(component) == false)
- {
- getBehaviorId(behavior);
- }
- }
-
- @SuppressWarnings("unchecked")
- public List getBehaviors(Class type)
- {
- final int len = component.data_length();
- final int start = component.data_start();
- if (len < start)
- {
- return Collections.emptyList();
- }
-
- List subset = new ArrayList<>(len);
- for (int i = component.data_start(); i < len; i++)
- {
- Object obj = component.data_get(i);
- if (obj != null && obj instanceof Behavior)
- {
- if (type == null ||
type.isAssignableFrom(obj.getClass()))
- {
- subset.add((M)obj);
- }
- }
- }
- if (subset.isEmpty()) {
- return Collections.emptyList();
- }
- return Collections.unmodifiableList(subset);
- }
-
-
- public void
[wicket] branch wicket-6774 created (now bdf4706)
This is an automated email from the ASF dual-hosted git repository. papegaaij pushed a change to branch wicket-6774 in repository https://gitbox.apache.org/repos/asf/wicket.git. at bdf4706 WICKET-6774: rework of component state This branch includes the following new commits: new bdf4706 WICKET-6774: rework of component state The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference.
[jira] [Commented] (WICKET-6774) Separate model, behaviors and metadata into separate fields
[
https://issues.apache.org/jira/browse/WICKET-6774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17096364#comment-17096364
]
Emond Papegaaij commented on WICKET-6774:
-
[~svenmeier] my new implementation is smaller or equal in size in all cases,
except when a component has multiple behaviors and multiple metadata entries. I
think this condition is very rare (most applications will probably never
trigger it) and therefore the improvement in speed and readability of the code
is more important than the 24-32 bytes of additional memory used by the
allocation of a second array.
> 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: Major
>
> 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.3.4#803005)
[jira] [Commented] (WICKET-6774) Separate model, behaviors and metadata into separate fields
[
https://issues.apache.org/jira/browse/WICKET-6774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17096326#comment-17096326
]
Sven Meier commented on WICKET-6774:
We could keep all 'data' (model, metadata, behaviors and validators) in a
single object/array. The extra array of metaData and the behaviorIdList just
add to the memory usage.
> 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: Major
>
> 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.3.4#803005)
[jira] [Commented] (WICKET-6774) Separate model, behaviors and metadata into separate fields
[
https://issues.apache.org/jira/browse/WICKET-6774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17096310#comment-17096310
]
Martijn Dashorst commented on WICKET-6774:
--
When you mention the devil, you step on his tail: this newsletter
[https://www.javaspecialists.eu/archive/Issue278.html] tells (all) about Java
object sizes.
> 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: Major
>
> 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.3.4#803005)
[jira] [Commented] (WICKET-6774) Separate model, behaviors and metadata into separate fields
[
https://issues.apache.org/jira/browse/WICKET-6774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17096296#comment-17096296
]
Emond Papegaaij commented on WICKET-6774:
-
Hi [~thomas.heigl], these numbers are close to what I expected of a typical
application. I'm currently working on a complete rewrite of the state
management of components. The implementation is very likely to be faster,
cleaner and more compact. It does remain a hairy topic though. For the
manipulation of behaviors alone I need over 200 lines of code. I think I've
managed to eliminate BehaviorIdList, which is a huge win.
> 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: Major
>
> 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.3.4#803005)
[jira] [Commented] (WICKET-6775) Autocompelete suggestion list not read by screen reader
[ https://issues.apache.org/jira/browse/WICKET-6775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17096258#comment-17096258 ] Martin Tzvetanov Grigorov commented on WICKET-6775: --- Thank you for reporting this issue! Please send a Pull Request at https://github.com/apache/wicket ! > Autocompelete suggestion list not read by screen reader > --- > > Key: WICKET-6775 > URL: https://issues.apache.org/jira/browse/WICKET-6775 > Project: Wicket > Issue Type: Bug > Components: wicket-extensions >Affects Versions: 8.1.0 >Reporter: ramesh valasa >Priority: Major > > As part of accessibility compliance, we see autocomplete suggestion list is > not able to read by screen reader(NVDA). > use case: > - > Start NVDA and click on the autocomplete text field then type > some letters, we see suggestion list apears. Then use arrow key to navigate > among the list. screen reader is only promting the value in the textfield not > the value from the list. > Expected: > - > Screen reader read the value from the suggestio list when we navigate > through arrow keys also text field should have role="combobox". > > Solution direction: > -- > 1) Add unique id's to the suggestion list items > 2) when ever we navigation through list items using arrow key, add > aria-activedescendant attibute to text field with value as id of the list item > example: > [https://www.w3.org/WAI/GL/wiki/Using_aria-activedescendant_to_allow_changes_in_focus_within_widgets_to_be_communicated_to_Assistive_Technology] > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (WICKET-6776) Cache Urls returned from ServletWebRequest
[
https://issues.apache.org/jira/browse/WICKET-6776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17096256#comment-17096256
]
Thomas Heigl commented on WICKET-6776:
--
I solved this in my application by extending {{ServletWebRequest}} like this:
{code}
public class BaseWebRequest extends ServletWebRequest {
private Url clientUrl;
private Url url;
public BaseWebRequest(HttpServletRequest httpServletRequest, String
filterPrefix) {
super(httpServletRequest, filterPrefix);
}
@Override
public Url getClientUrl() {
if (clientUrl == null) {
clientUrl = new ImmutableUrl(super.getClientUrl());
}
return clientUrl;
}
@Override
public Url getUrl() {
if (url == null) {
url = new ImmutableUrl(super.getUrl());
}
return url;
}
static final class ImmutableUrl extends Url {
public ImmutableUrl(Url url) {
super(url);
}
@Override
public void setFragment(String fragment) {
throw new UnsupportedOperationException();
}
@Override
public void setQueryParameter(String name, Object value) {
throw new UnsupportedOperationException();
}
@Override
public void setProtocol(String protocol) {
throw new UnsupportedOperationException();
}
@Override
public void setContextRelative(boolean contextRelative) {
throw new UnsupportedOperationException();
}
@Override
public void setPort(Integer port) {
throw new UnsupportedOperationException();
}
@Override
public void setHost(String host) {
throw new UnsupportedOperationException();
}
}
}
{code}
Urls are mutable so I'm putting an immutable wrapper around them to guard
against accidental changes.
> Cache Urls returned from ServletWebRequest
> --
>
> Key: WICKET-6776
> URL: https://issues.apache.org/jira/browse/WICKET-6776
> Project: Wicket
> Issue Type: Improvement
> Components: wicket-core
>Affects Versions: 8.7.0, 9.0.0-M5
>Reporter: Thomas Heigl
>Priority: Major
>
> Profiling in production showed that {{ServletWebRequest.getUrl()}} and
> {{ServletWebRequest.getClientUrl()}} are called many times during request
> processing and allocate a lot of objects.
> Each call to {{ServletWebRequest.getUrl()}} creates a new {{Url}} object that
> internally creates two new {{ArrayLists}}.
> {{ServletWebRequest.getClientUrl()}} creates a new URL and involves a lot of
> complex parsing logic.
> Both methods are invoked during request mapping. We have about 350 registered
> mappers, so these methods are called *at least* 350 times on each request.
> Both values should be cached.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (WICKET-6776) Cache Urls returned from ServletWebRequest
Thomas Heigl created WICKET-6776:
Summary: Cache Urls returned from ServletWebRequest
Key: WICKET-6776
URL: https://issues.apache.org/jira/browse/WICKET-6776
Project: Wicket
Issue Type: Improvement
Components: wicket-core
Affects Versions: 9.0.0-M5, 8.7.0
Reporter: Thomas Heigl
Profiling in production showed that {{ServletWebRequest.getUrl()}} and
{{ServletWebRequest.getClientUrl()}} are called many times during request
processing and allocate a lot of objects.
Each call to {{ServletWebRequest.getUrl()}} creates a new {{Url}} object that
internally creates two new {{ArrayLists}}.
{{ServletWebRequest.getClientUrl()}} creates a new URL and involves a lot of
complex parsing logic.
Both methods are invoked during request mapping. We have about 350 registered
mappers, so these methods are called *at least* 350 times on each request.
Both values should be cached.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (WICKET-6774) Separate model, behaviors and metadata into separate fields
[
https://issues.apache.org/jira/browse/WICKET-6774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17096219#comment-17096219
]
Thomas Heigl commented on WICKET-6774:
--
I'm closing my original PR because it does not make sense from a
memory/serialization perspective.
> 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: Major
>
> 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.3.4#803005)
[jira] [Comment Edited] (WICKET-6774) Separate model, behaviors and metadata into separate fields
[
https://issues.apache.org/jira/browse/WICKET-6774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17096215#comment-17096215
]
Thomas Heigl edited comment on WICKET-6774 at 4/30/20, 6:46 AM:
Hi [~papegaaij]:
I fully agree with your analysis. There is some room for improvement within the
current state management but there are no low hanging fruits and decisions have
to be based on real usage.
A rough estimate for my application:
||State||Components||Description||
|Model|50%|
|Behavior|15-25%|Mostly {{AjaxLink}} and {{AttributeAppender}}|
|Metadata|1%|Mostly because of {{setMarkupId()}}|
So metadata would be an obvious target for a flag in our case.
Can someone else share their estimates as well?
was (Author: thomas.heigl):
Hi [~papegaaij]:
I fully agree with your analysis. There is some room for improvement within the
current state management but there are no low hanging fruits and decisions have
to be based on real usage.
A rough estimate for my application:
||State||Components||Description||
|Model|50%|
|Behavior|15-25%|Mostly {{AjaxLink}} and{{AttributeAppender}}|
|Metadata|1%|Mostly because of {{setMarkupId()}}|
So metadata would be an obvious target for a flag in our case.
Can someone else share their estimates as well?
> 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: Major
>
> 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.3.4#803005)
[jira] [Commented] (WICKET-6774) Separate model, behaviors and metadata into separate fields
[
https://issues.apache.org/jira/browse/WICKET-6774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17096215#comment-17096215
]
Thomas Heigl commented on WICKET-6774:
--
Hi [~papegaaij]:
I fully agree with your analysis. There is some room for improvement within the
current state management but there are no low hanging fruits and decisions have
to be based on real usage.
A rough estimate for my application:
||State||Components||Description||
|Model|50%|
|Behavior|15-25%|Mostly {{AjaxLink}} and{{AttributeAppender}}|
|Metadata|1%|Mostly because of {{setMarkupId()}}|
So metadata would be an obvious target for a flag in our case.
Can someone else share their estimates as well?
> 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: Major
>
> 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.3.4#803005)
