Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
Clear All
new posts

    Issue with selection in large TreeGrid data (with nested children)

    Hi,

    I am struggling with the following issue. I will be happy if someone can suggest any idea to solve this performance problem.

    With the following piece of code, you will get a TreeGrid with columns. (screenshot attached).

    The performance issues starting when the tree includes 3 or more nested children combined with large piece of data.
    (Large data for example is when the root containes at least 5 children which each one of them containes at least 5000 children which containes more children).

    After the data got rendered, selecting one of the rows (main or nested), freezes the UI for a few seconds.

    In my case, the desired root data will contain dozens / hundreds rows with 3 or more children levels, in total ~50K rows.

    (When using 2 or less nested children - there are no visual performance issues. You can try it if you delete all the children property in the second loop).

    Code:
    var tree = isc.Tree.create({
            modelType: "children",
            childrenProperty: "children",
            nameProperty: "Name",
            root: newData
          });
    
          var myTreeGrid = isc.TreeGrid.create({
            ID: "TreeGrid",
            data: tree,
            height: 500,
            width: 1000,
            fields: [
              { name: "Name" },
              { name: "nodeType" },
              { name: "nodeTypeText" },
              { name: "nodeTitle" },
              { name: "detailsText" },
              { name: "detailsTextForPrint" },
              { name: "productId" },
              { name: "amountToPay" },
              { name: "itemOrPriceModifierId" },
              { name: "itemDetails" }
            ]
          });
    
          for (var i = 0; i < 5; i++) {
            var newData = {
              EmployeeId: "new",
              Name: "new " + i,
              children: [{}]
            };
    
            for (var j = 0; j < 10000; j++) {
              newData.children.push({
                Name: "ch" + i + " " + j,
                nodeType: "2",
                nodeTypeText: "Payment" + i + " " + j,
                nodeTitle: "nodeTitle" + i + " " + j,
                detailsText: "QQQ" + i + " " + j,
                detailsTextForPrint: "EmployeeId" + Math.random(),
                productId: Math.random(),
                amountToPay: Math.random(),
                itemOrPriceModifierId: Math.random(),
                itemDetails: "EmployeeId" + i + " " + j,
                isFolder: true,
                parent: newData,
                children: [
                  {
                    Name: "www",
                    nodeTypeText: "www",
                    children: [
                      {
                        Name: "eee",
                        nodeTypeText: "eee",
                        children: [
                          {
                            Name: "ttt",
                            nodeTypeText: "ttt"
                          }
                        ]
                      }
                    ]
                  }
                ]
              });
            }
            myTreeGrid.addData(newData);
          }
    2019-10-06_151900.pdf
    tnx!

    #2
    Performance of selection is generally going to be related to the number of visible nodes, no matter the size of the tree.

    It looks like after populating the tree with data, you must be opening *a lot* of folders, probably programmatically, as it would take a very long time otherwise.

    It doesn't seem realistic to simulate a situation that would take an end user 30-40 minutes of clicking to create, as well as make a tree so vast it would be impossible to navigate effectively.

    Comment


      #3
      Hi, tnx for your answer.

      I just want to make sure you understand the issue..
      The problem is the Selection (not creation) of one of the rows after the data is ready. (The code in the first post is just a simple way to create a large tree data).

      As I mentiond before, this issue occurs with large data + tree which have 3+ levels.
      Otherwise, even with ~100K rows in flat tree performance are fine.

      The end user will not create such data.
      I recieve such data set as a snapshot to work with it.

      The thing here is the 'Selection'.
      There is a performance problem with selction on structures as I explained.

      Is a fix for this issue is something u will can take in account for future versions?

      tnx again,
      Kostia

      Comment


        #4
        Please re-read our response. We're talking about which folders are open hence how many are *visible*. We are not talking about how many are loaded.

        Comment


          #5
          I want to clarify again the scenario - the tree is prepared according to the code I shared above - this works fine and is simulating a reasonable real-life data set.
          While all the tree is still collapsed (only the nodes at the first level are showing) - the user just selects a row (not expanding it - just click on the row to highlight it) - the UI will freeze for a several long seconds!
          There is no addition code or other operations performed grammatically - you can simulate this in your example viewer using the code I provided.
          I have tracked down the root cause for that freeze to the following line in your source code:

          Tree.js -> getOpenList function -> "list.concat(this.getOpenList...)..."


          Click image for larger version

Name:	111.jpg
Views:	116
Size:	65.9 KB
ID:	259681


          Attached Files

          Comment


            #6
            We've made a few improvements to SC 12.0+ that should reduce overhead for your sample code (including the code you referenced). (Did you report the version of SC you're using?) These will be in the nightly builds dated 2019-10-23 and beyond.

            While there's still a delay when clicking between records, it should be noticeably improved.

            We're considering further improvements as well to target the remaining delay, but it's not clear yet how feasible they may be for us.

            Comment


              #7
              I was wondering what was done for V13.0 of the SmartGWT on this issue. We also are using the treegrid and when we put up say children 5000 rows on the screen, it renders and scrolls quickly but when we have to click on one of the nodes, the UI will just wait and we get the (Wait or Kill) command on the browser. The browser will hang for about 10-30 seconds until we click on something else. We're using V13.0 p20230927 and we're seeing the same issue. What can be done to get this so that if we click on the node, the entire browser won't lock up.

              Comment


                #8
                Hi dwonger, the issue as reported was already fixed, and was fixed for data volume that is far higher than what you report.

                It's likely that your problem is not the same.

                What's we'd suggest is:

                1. make sure you are running in compiled mode, not development mode. Development node can be a lot slower in ways we can't really reduce. But end users would never experience those problems.

                2. run a profiler on the code. You want to look first to see if perhaps you have something like a very expensive SelectionChanged handler - perhaps something causing hundreds of redraws in response to changes in the selection on the tree?

                If neither suggestion helps, we would need a way to reproduce the problem (as we noted, the original problem is already fixed).

                Also, for any such follow-up question, it would be good to post it in the SmartGWT forum (this is the SmartClient forum) unless you want to provide a SmartClient-based test case, which is also welcome.

                Comment


                  #9
                  Thanks - I'll take a look and if I have an issue I'll put it in the SmartGWT forum - it was the same issue so it's why I followed up here.

                  Comment

                  Working...
                  X