From Ekaterina:

Aurora NodeMemory.TreeItem footprint results are still lower than what we had before regression was introduced:

 b091: 63,200 // the last build before regression was introduced
 b092: 40,000
 b151: 42,000
 b153: 56,000
 b159: 46,000
 b166: 48,000

However, if I run attached TreeItemFootprint (attached to RT-18344) with 16mb of heap I see that the number of
objects we are able to create is actually much bigger:

      2.1-b02: 21,800
controls-b166: 24,200

The issue with NodeMemory.TreeItem test is that it started to run slower and as result
doesn't reach free memory threshold in 240 seconds (the timeout the test is run with).
This is why it reports low footprint results.

Attached TreeViewModifyPerformance.java demonstrates new performance issue in TreeView.
This test just creates 2 tree views and does add N items into first/second tree view and removes
all items from second/first one on each pulse. Two tree views are used to guarantee the same load on every pulse.

JPA profiles show that we started to spend 29% of time in TreeView.getRow(TreeItem).
The cause is because we started to call this method not only for root item.

I instrumented getRow method and I see that in case of fx2.0.2-b08 the expression on line 4
is always true and as result we return immediately.


     1 public int getRow(TreeItem<T> item) {
     2 if (item == null) {
     3 return -1;
     4 } else if (isShowRoot() && item.equals(getRoot())) {
     5 return 0;
     6 }
     7
     8 int row = 0;
     9 TreeItem<T> i = item;
    10 TreeItem<T> p = item.getParent(); 11
    12 TreeItem<T> s;
    13 List<TreeItem<T>> siblings;
    14
    15 while (!i.equals(getRoot()) && p != null) {
    16 siblings = p.getChildren();
    ...


In case of fx2.1-controls-scrum-b166 this is not the case and we go into 'while' and other staff
As result the performance dropped in several times, here are the number I am getting
on my windows laptop (in fullspeed mode)
        fx2.0.2-b08: ~30 fps
fx2.1-controls-b166: ~10 fps

TreeView.getRow is called from TreeView$TreeViewFocusModel$2.handle(...).

Why we call it for all tree items and not only for root one anymore?
Could it be some functional bug?
 

Steps to run TreeViewModifyPerformance:
> javac -cp "..." -d . TreeViewModifyPerformance.java
> java -cp "..." TreeViewModifyPerformance -allocCnt 1000