Details

    • Type: Bug
    • Status: Closed
    • Priority: P3
    • Resolution: Fixed
    • Affects Version/s: fx2.1
    • Fix Version/s: fx2.1
    • Component/s: javafx
    • Labels:

      Description

      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

        Attachments

          Activity

            People

            • Assignee:
              jgiles Jonathan Giles
              Reporter:
              jgiles Jonathan Giles
            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:
                Imported: