[Perf] Large performance drop in 32.13.0 vs 32.12.2

[aerogt3]

High-level description

When displaying approximately 400 vtkSTLReaders of ~220Mb in total size (gzipped), the 3D scene is unusable: rotating the model renders at about 1-2 FPS in 32.13.0. In 32.12.2 it's too fast/smooth to count.

v32.12.2...v32.13.0
There are no vtkActor2D at all in this case, but it seems there are loops which may run regardless.

Steps to reproduce

Load/display a large number of vtkSTLReaders, then zoom/rotate/resetCamera. All are slow.

Detailed Current Behavior

Did not profile as it's clear from just interacting with the scene.

Environment

firefox 144.0.2 on ubuntu 2204
chrome 142.0 on windows 11

[finetjul]

Performance hit should come from publicAPI.getViewPropsWithNestedProps()
Can you try to do something like below to see if that improves performance ?

publicAPI.getViewPropsWithNestedProps = () => {
    let allPropsArray = [];
    // Handle actor2D instances separately so that they can be overlayed and layered
    const actors2D = publicAPI.getActors2D();
    if (actors2D.len > 0)  {
      // Sort the actor2D list using its layer number
      actors2D.sort((a, b) => a.getLayerNumber() - b.getLayerNumber());
      // Filter out all the actor2D instances
      const newPropList = model.props.filter((item) => !actors2D.includes(item));
      for (let i = 0; i < newPropList.length; i++) {
        gatherProps(newPropList[i], allPropsArray);
      }
      // Finally, add the actor2D props at the end of the list
      // This works because, when traversing the render pass in vtkOpenGLRenderer, the children are
      // traversed in the order that they are added to the list
      allPropsArray = allPropsArray.concat(actors2D);
    }
    else {
       for (let i = 0; i < model.props.length; i++) {
          gatherProps(model.props[i], allPropsArray);
       }
    }
    return allPropsArray;

[finetjul]

nevermind, I just re-read the code and performance hit can also comes from publicAPI.addMissingNodes().
My take is that one should get ride of .concat, .filter, .sort , .splice... function calls that are costly.

[finetjul]

@sankhesh I thought your change was only impacting 2D actors... WDYT ?

[finetjul]

Performance hit should come from publicAPI.getViewPropsWithNestedProps() Can you try to do something like below to see if that improves performance ?

nevermind, I just re-read the code and performance hit can also comes from publicAPI.addMissingNodes().

According to this comment, it would be odd that addMissingNodes() is the culprit in your example with a static scene.

The following should improve things, but probably does not tackle the real problem:

publicAPI.addMissingNodes = (dataObjs, enforceOrder = false) => {
    if (!dataObjs || !dataObjs.length) {
      return;
    }

    for (let index = 0; index < dataObjs.length; ++index) {
      const dobj = dataObjs[index];
      const node = publicAPI.addMissingNode(dobj);
      if (
        enforceOrder &&
        node !== undefined &&
        model.children[index] !== node
      ) {
        // enforce that `node` is at the index'th position
        for (let i = index + 1; i < model.children.length; ++i) {
          if (model.children[i] === node) {
            for (let j = i; j > index; --j) {
              model.children[j] = model.children[j -1];
            }
            model.children[index] = node;
            break;
          }
        }
      }
    }
  };

[aerogt3]

I dropped that into SceneGraph/ViewNode and I don't recognize a difference vs. 32.13.0.

I can try to create a test case towards the end of week 46-47, but it will take time to either reproduce with vtkCubeActors, or programmatically generate many random STL files.

[finetjul]

I created 1000 cones in this example.

Each time we render a cone, we "pre-build" the mapper. And it searches the camera openGL mapper.

getViewNodeFor() is slow because the camera is the last child.

The OpenGL camera used to (32.12.2) be the first child. In v33.0.0, it is the last child. Hence the performance hit.

This is because enforceOrder enforces the items from publicAPI.getViewPropsWithNestedProps() to be indexed 0 to N-1 (where N is the length of publicAPI.getViewPropsWithNestedProps()). This is not mandatory, it should only make sure that the order within the list is enforced.

I think that:

• the OpenGLCamera must always be the first element, enforceOrder behavior should be revised.
• the buildPass should not search for the camera node if it has already be found
• minor improvements like here and here can still be made.