Hi, Anton.
On 08.05.15 12:23, Anton V. Tarasov wrote:
1314 /**
1315 * Determines the bounds which will be displayed on the screen.
1316 *
1317 * @return the visible part of bounds in the coordinate space
of this comp
1318 */
1319 private Rectangle getRecursivelyVisibleBounds() {
Could you please clarify the comment, it's not quite clear from the
first glance. Something like:
"the bounds of a visible part of the component relative to..."
The patch updated:
http://cr.openjdk.java.net/~serb/8071306/webrev.04
2.
100 * The components in this container.
101 * @see #add
102 * @see #getComponents
103 */
104 private java.util.List<Component> component = new ArrayList<>();
May be it's worth to rename the field? The "component" name is odd...
I suppose it wasn't changed, because this name is used in the
serialization for a long time. Plus there are a bunch of the similar
vars like: tmpComponent etc. I can do it later for jdk9 only.
Regards,
Anton.
On 07.05.2015 3:39, Sergey Bylokhov wrote:
Hello.
Please review the fix for a jdk9. I plan to backport it to jdk8u60.
Description.
An UIworks really slowly, when an application has a lot of components
in one container, and these components should be disabled one by one.
The reason is the next sequence of methods calls:
Component.setEnabled->updateCursorImmediately()-> some cursor related
staff->GlobalCursorManager._updateCursor->Container.findComponentAt()-iteration
over all components in the container.....-> twice....
You can imagine how it works in case of 10000 components in the
container.
Note that in the bug report described difference jdk6 vs jdk8 -> 1sec
vs 6 sec. This was caused by the two fixes, one of which adds
checkTreeLock() and in another one a simple array of components was
replaced by the ArrayList. Since code was added to the really hot
method we got so big slowdown.
To fix the problem I suggest two different approaches:
- Container.java: Fix a general case, by eliminating a second
iteration in the hot loop.
- Component.java: Totally eliminates cursor machinery, if component
cannot affect current cursor.
Some speedup measurements on my local system:
- Simple removing of checkTreeLock() will partly solve a regression
reported by the user(12 sec -> 5 sec).
- Changes in the loop will speedup the code in the worse case(5->2 sec)
- The changes in the Component.java will change the performance from
2 sec to 100< ms
Test case which was added was improved from 10 seconds to 80 ms.
JMH test:
http://cr.openjdk.java.net/~serb/8071306/SetEnabledPerformanceTest.java
Fixedversion:
Benchmark Mode Cnt
Score Error Units
SetEnabledPerformanceTest.testContains thrpt 5 301300,813
± 17338,045 ops/ms
SetEnabledPerformanceTest.testFindComponentAt thrpt 5 20,521
± 0,269 ops/ms
SetEnabledPerformanceTest.testGetComponentAt thrpt 5 22,297
± 1,264 ops/ms
SetEnabledPerformanceTest.testSetEnabled thrpt 5 711,120
± 19,837 ops/ms
Base version:
Benchmark Mode Cnt
Score Error Units
SetEnabledPerformanceTest.testContains thrpt 5 299145,642
± 2120,183 ops/ms
SetEnabledPerformanceTest.testFindComponentAt thrpt 5 1,101
± 0,012 ops/ms
SetEnabledPerformanceTest.testGetComponentAt thrpt 5 6,792
± 0,097 ops/ms
SetEnabledPerformanceTest.testSetEnabled thrpt 5 0,464
± 0,020 ops/ms
Bug: https://bugs.openjdk.java.net/browse/JDK-8071306
Webrev can be found at:
http://cr.openjdk.java.net/~serb/8071306/webrev.03
--
Best regards, Sergey.
--
Best regards, Sergey.
