-
Bug
-
Resolution: Duplicate
-
P2
-
7u40
-
all
This is a regression in SB 1.1 b29 compared to b28.
The scenario to highlight the issue is:
- load the attached layout perfIssue.fxml
- make sure Hierarchy and Inspector panels are visible, and in Inspector select the Code panel
- in Hierarchy use pull down to select "Show fx:id"
- select the Button with fx:id=a
- use down arrow key of the keyboard to move to the Button with fx:id=b then c and so on ==> at each press it takes 1+ second to see the fx:id text field in Code panel of the Inspector updated, the selection on Content updated. This is instantaneous with SB 1.1 b28.
- in Hierarchy if you double click the fx:id value of a Button it takes here again 1+ second to enter the edit mode. This is instantaneous with SB 1.1 b28.
Investigation
SB 1.1 b29 is based on FX 2.2.40 b33 while b28 is based on FX 2.2.40 b30 hence a gap of 3 Java builds.
I constructed a custom SceneBuilder bundle using the same code as SB 1.1 b29 but based this time on FX 2.2.40 b31 and b32 to narrow down root cause.
Like that I isolated the perf drop occurs with FX 2.2.40 b32 (worth saying there's very few SB code changes and none likely to hit it like that).
For what is about FX platform changes there's only RT-29975 andRT-31189 between FX 2.2.40 b31 and b32, and the latter JIRA is about sample code.
I measured that the fix of RT-29975 allows to save up to 50% of heap memory on Windows and Linux (15% on Mac), which is vastly positive. But at that time I didn't notice the performance drop.
We need to keep the memory savings but without the perf penalty.
The scenario described above is directly inspired from a QE perf test.
Quoting Dmitry:
"It's not obvious to person that not used to read Aurora performance reports, but SQE tests found only one really serious issue with b29 changeset 5782d8e28dbd from 2013-07-11.
Problematic test is sb_autotest_noncached_CodeTabResponceTest that's result is 2.166+\-0.361s for b29. It was just about 0.504+\-0.15s in b28.
Let me describe test algorithm, it contains following steps:
-add a button
-set up fx:id from Inspector
-repeat previous 2 steps N times (where N > element cash size, currently N=15)
-select first button in Hierarchy, check that fx:id field is updated
-reset timer and press down arrow key to select next button in Hierarchy
-check that fx:id field value is updated to selected element's id
-stop timer and store value
Detailed sb_autotest_noncached_CodeTabResponceTest test results could be found here http://aurora.ru.oracle.com/performance/faces/RunsCompare.xhtml?names=2013-07-18_19-23-22 in testSuite.sb_autotest_noncached_CodeTabResponceTest.REAL_TIME section.
"
The scenario to highlight the issue is:
- load the attached layout perfIssue.fxml
- make sure Hierarchy and Inspector panels are visible, and in Inspector select the Code panel
- in Hierarchy use pull down to select "Show fx:id"
- select the Button with fx:id=a
- use down arrow key of the keyboard to move to the Button with fx:id=b then c and so on ==> at each press it takes 1+ second to see the fx:id text field in Code panel of the Inspector updated, the selection on Content updated. This is instantaneous with SB 1.1 b28.
- in Hierarchy if you double click the fx:id value of a Button it takes here again 1+ second to enter the edit mode. This is instantaneous with SB 1.1 b28.
Investigation
SB 1.1 b29 is based on FX 2.2.40 b33 while b28 is based on FX 2.2.40 b30 hence a gap of 3 Java builds.
I constructed a custom SceneBuilder bundle using the same code as SB 1.1 b29 but based this time on FX 2.2.40 b31 and b32 to narrow down root cause.
Like that I isolated the perf drop occurs with FX 2.2.40 b32 (worth saying there's very few SB code changes and none likely to hit it like that).
For what is about FX platform changes there's only RT-29975 and
I measured that the fix of RT-29975 allows to save up to 50% of heap memory on Windows and Linux (15% on Mac), which is vastly positive. But at that time I didn't notice the performance drop.
We need to keep the memory savings but without the perf penalty.
The scenario described above is directly inspired from a QE perf test.
Quoting Dmitry:
"It's not obvious to person that not used to read Aurora performance reports, but SQE tests found only one really serious issue with b29 changeset 5782d8e28dbd from 2013-07-11.
Problematic test is sb_autotest_noncached_CodeTabResponceTest that's result is 2.166+\-0.361s for b29. It was just about 0.504+\-0.15s in b28.
Let me describe test algorithm, it contains following steps:
-add a button
-set up fx:id from Inspector
-repeat previous 2 steps N times (where N > element cash size, currently N=15)
-select first button in Hierarchy, check that fx:id field is updated
-reset timer and press down arrow key to select next button in Hierarchy
-check that fx:id field value is updated to selected element's id
-stop timer and store value
Detailed sb_autotest_noncached_CodeTabResponceTest test results could be found here http://aurora.ru.oracle.com/performance/faces/RunsCompare.xhtml?names=2013-07-18_19-23-22 in testSuite.sb_autotest_noncached_CodeTabResponceTest.REAL_TIME section.
"