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:	25
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

            Working...
            X