Virtual Fit Slow

[peterhollender]

Virtual fit takes a few minutes to run, and it is unclear why the runtime is so long. I'm guessing that the estimation of normals to curved skin points is the bottleneck, but it feels like there is room for improvement. We should profile performance and see if we can't improve.

[ebrahimebrahim]

Agreed there is room for improvement -- I never had to deal with a few minutes though. It's usually under a minute for me. But it depends on the size of the search space and the resolution of the spherical interpolator.

The normals estimation is not a bottleneck I think. That's all vectorized pretty well.

Is it hanging mainly on "building spherical interpolator" or on "searching through candidates"?

[peterhollender]

Interpolator is taking 20s, and searching through poses is taking 2:40. And this is relaxing the step size in the virtual fit options:

    "virtual_fit_options": {
        "units": "mm",
        "transducer_steering_center_distance": 30.0,
        "steering_limits": [
            [
                -20.0,
                20.0
            ],
            [
                -20.0,
                20.0
            ],
            [
                -30.0,
                80.0
            ]
        ],
        "pitch_range": [
            -10.0,
            80.0
        ],
        "pitch_step": 10.0,
        "yaw_range": [
            -65.0,
            65.0
        ],
        "yaw_step": 10.0,
        "planefit_dyaw_extent": 15.0,
        "planefit_dyaw_step": 3.0,
        "planefit_dpitch_extent": 15.0,
        "planefit_dpitch_step": 3.0
    },

[ebrahimebrahim]

The pose search taking longer makes sense -- the iteration over candidate poses is not vectorized.

But from your options that's not tooo dense of a search grid, it looks like ~100 pts, so I do worry that maybe something is wrong. Worth investigating.

If nothing is wrong a low hanging fruit is to parallelize the search through poses, since each poses is really analyzed independently.

[peterhollender]

The pose search taking longer makes sense -- the iteration over candidate poses is not vectorized.

But from your options that's not tooo dense of a search grid, it looks like ~100 pts, so I do worry that maybe something is wrong. Worth investigating.

If nothing is wrong a low hanging fruit is to parallelize the search through poses, since each poses is really analyzed independently.

Please investigate. In the MATLAB code, I was able to build a tool with a little navigation GUI that would update the position of the array along the surface of the head in basically real-time, including updating a fancier virtual fitting that did element-wise raytracing to determine if an element path was blocked by the sinuses. The computation time per search position is way higher than expected.

[ebrahimebrahim]

Adding some notes here from my first investigation; there will be more to come.

I looked at the spherical interpolator construction to see if I can get rid of the python loop that repeatedly uses a cell locator to intersect line rays with the mesh. I tried parallelizing it first, but the gain was minimal due to the setup cost of a vtk cell locator.

Another idea worked much better: there is a trimesh ray intersection utility that is readily available to us because we already have trimesh as a dependency. Using trimesh.ray.ray_pyembree.RayMeshIntersector.intersects_location greatly sped up this loop.

Another bottleneck is the construction of the scipy.interpolate.LinearNDInterpolator. I still need to look into optimizations for this.

Finally there is the pose searching loop itself which is currently a slow python loop. Internally all the plane fitting operations and so on are vectorized, so that's good. But the external pose search is not vectorized. Next I want to look into possibly vectorizing, and if that's out of reach for now then at least multiprocessing should provide a big speedup. UPDATE: The pose search loop is very small, just hundreds of points. Parallel processing for it is not worth it. If it's slow for you, then that's not because of the python loop overhead but rather because each iteration is slow. Each iteration does an SVD for the plane-fitting, which is supposed to be fast. But depending on what linear algebra libraries numpy finds, it may be the bottleneck in some cases.

[ebrahimebrahim]

I've got two PRs up for this now, but I need to know more to see if they will solve the problem:

• Speed up virtual fitting #374 (big speedup for intelx86 cpu, using raytracing)
• Speed up virtual fitting SlicerOpenLIFU#474 (small speedup to pose search while in slicer)

As you can see in the profiling info at #374, under the same conditions as yours in this issue, the pose search takes a few seconds, not minutes, for me, even before these changes. So I suspect that something else is going on, possibly something to do with linear algebra libraries on each of our systems.

@peterhollender, here is an extension package that contains the changes from both PRs: 33241-linux-amd64-SlicerOpenLIFU-gitb71cfd8-2025-08-19.tar.gz. Remember to reinstall python requirements from the button under the "advanced" section of the OpenLIFUHome module.

Can you try this and see how it works on your machine? Does it feel instant like the GIF shown here? If not then can you run the following in your Slicer python console and share the output?

import numpy as np, scipy, sys
print(sys.version)
print("numpy:", np.__version__)
print("scipy:", scipy.__version__)
np.__config__.show()

This may reveal some difference in our linear algebra libraries, which could inform a new requirement or reproduce the slowness on my end for further testing.