import trimesh takes 5 seconds on Windows

[JP01]

Hi
Importing trimesh takes a very long time on Windows python311.

Compared to numpy (less than 0.4seconds) simply IMPORTING trimesh takes nearly 5 seconds.

Anyone know why or how to fix?
Cheers

[mikedh]

Hey, yeah it's often a little slow to import, although its usually on the order of half a second for me. I'd try running the import in a profiler to see if something jumps out:

from pyinstrument import Profiler

with Profiler() as P:
    import trimesh
P.print()

On my machine:

mikedh@orion:trimesh$ python prof.py 

  _     ._   __/__   _ _  _  _ _/_   Recorded: 14:30:17  Samples:  247
 /_//_/// /_\ / //_// / //_'/ //     Duration: 0.541     CPU time: 2.665
/   _/                      v5.1.1

Profile at /home/mikedh/trimesh/prof.py:3

0.540 <module>  prof.py:1
└─ 0.540 <module>  trimesh/__init__.py:1
   ├─ 0.251 <module>  trimesh/bounds.py:1
   │  ├─ 0.200 <module>  trimesh/convex.py:1
   │  │  └─ 0.200 <module>  trimesh/triangles.py:1
   │  │     └─ 0.198 <module>  trimesh/points.py:1
   │  │        ├─ 0.183 <module>  trimesh/grouping.py:1
   │  │        │  └─ 0.178 <module>  scipy/spatial/__init__.py:1
   │  │        │        [54 frames hidden]  scipy, numpy, re
   │  │        └─ 0.010 <module>  trimesh/visual/__init__.py:1
   │  │           └─ 0.008 <module>  trimesh/visual/texture.py:1
   │  │              └─ 0.008 <module>  trimesh/visual/material.py:1
   │  │                 └─ 0.008 <module>  PIL/Image.py:1
   │  └─ 0.051 <module>  trimesh/nsphere.py:1
   │     ├─ 0.043 <module>  scipy/optimize/__init__.py:1
   │     │     [3 frames hidden]  scipy
   │     └─ 0.008 <module>  psutil/__init__.py:1
   ├─ 0.154 <module>  trimesh/creation.py:1
   │  └─ 0.152 <module>  trimesh/base.py:1
   │     ├─ 0.109 <module>  trimesh/graph.py:1
   │     │  └─ 0.107 <module>  networkx/__init__.py:1
   │     │        [24 frames hidden]  networkx, importlib
   │     ├─ 0.029 <module>  trimesh/repair.py:1
   │     │  └─ 0.029 <module>  trimesh/path/__init__.py:1
   │     │     └─ 0.027 <module>  trimesh/path/path.py:1
   │     │        ├─ 0.015 <module>  trimesh/path/polygons.py:1
   │     │        │  └─ 0.011 <module>  shapely/__init__.py:1
   │     │        └─ 0.008 <module>  trimesh/path/exchange/export.py:1
   │     │           └─ 0.006 <module>  trimesh/path/exchange/svg_io.py:1
   │     └─ 0.008 <module>  trimesh/exchange/export.py:1
   │        └─ 0.006 <module>  trimesh/exchange/urdf.py:1
   │           └─ 0.006 <module>  trimesh/version.py:1
   │              └─ 0.006 _get_version  trimesh/version.py:13
   │                 └─ 0.006 version  importlib/metadata/__init__.py:980
   │                       [2 frames hidden]  importlib
   ├─ 0.082 <module>  trimesh/boolean.py:1
   │  ├─ 0.064 <module>  numpy/__init__.py:1
   │  │     [17 frames hidden]  numpy, typing
   │  └─ 0.016 <module>  trimesh/interfaces/__init__.py:1
   │     └─ 0.014 <module>  trimesh/interfaces/blender.py:1
   │        └─ 0.012 <module>  trimesh/util.py:1
   │           └─ 0.010 <module>  logging/__init__.py:1
   │                 [4 frames hidden]  traceback, _colorize, dataclasses
   ├─ 0.043 <module>  trimesh/exchange/load.py:1
   │  └─ 0.043 <module>  trimesh/exchange/cascade.py:1
   │     └─ 0.041 create_dynamic  <built-in>
   └─ 0.008 <module>  trimesh/voxel/__init__.py:1
      └─ 0.008 <module>  trimesh/voxel/creation.py:1
         └─ 0.008 <module>  trimesh/voxel/base.py:1
            └─ 0.008 <module>  trimesh/voxel/morphology.py:1
               └─ 0.006 __getattr__  scipy/__init__.py:129
                     [4 frames hidden]  importlib, scipy

Which is mostly scipy and networkx.

[JP01]

Thanks!!
I have tracked down the issue to the shutil library. There are a few trimesh modules that attempt to find binaries when imported. Perhaps on windows it's slow?

I am just trying to see why the slowness.

The culprits:

[JP01]

I'm not sure why it's so slow on Windows - maybe I just have a lot of stuff in the PATH.

I'm wondering if these module level checks could be moved into functions that are called only when needed?
That would incur the lookup cost on first run of whatever function needed the executable path - but that feels like it should be fine?

Though looking into it a bit more - everything is 'public' so it could potentially break client APIs that are relying on these for whatever reason.
EG in interfaces/blender.py if anyone is relying on the 'exists' module attribute then that will be no longer available :s

_blender_executable = util.which("blender", path=_search_path)
exists = _blender_executable is not None

I think you could maintain the API if required with a lazy evaluator of some kind but I'm not exactly sure.

[mikedh]

Oh that's interesting that shutil.which is so slow. Regardless yeah I agree there should be less work done in general on import. I'm not sure if it's worth it to not import core things like scipy, but the which calls seems like low hanging fruit.

I sketched out a way to defer the which in 4cd17cc which seems promising, although we'd have to generate trimesh.boolean._engines (and the draco one) lazily too.