ChimeraX sometimes very slow to start

[Tom Goddard]

ChimeraX sometimes takes 30 seconds to a minute to startup. We should study this and document under what conditions it happens so users can avoid the slow startups.

On Linux servers with a network file system it is very slow and Brian Hudson of the RCSB complained it is much slower to start and show a map than Chimera. I have seen the same thing starting ChimeraX on plato, taking 30 seconds to a minute. Here is the mailing list discussion with Brian.

​https://www.rbvi.ucsf.edu/pipermail/chimerax-users/2022-September/004233.html

Greg Couch suggests that the current singularity image for running ChimeraX on plato may be much faster because it only has to load one large image file from the network file system. We should test that.

On macOS, Eric, Elaine and I have also noted that ChimeraX sometimes takes 30 seconds to start. But most times it takes 1 second or less. The slow start may be because the Mac has been restarted and the thousands of ChimeraX Python files are no longer in memory cache. Or it may be a notarization verification or optimization step starting a new ChimeraX installation. Or it could sometimes be querying the Toolshed. Need to investigate this further.

[Eric Pettersen]

I note that the DICOM bundle is imported at startup, apparently only because it needs to call chimerax.map.add_map_format() for DICOMMapFormat. On my 1.6 development build, with various libraries likely still in disk/memory cache, this startup import took .13 seconds. In ChimeraX 1.4, which I hadn't recently started, it took .66 seconds. I started the timing after the non-DICOM imports at the top of dicom/__init__.py

So, in addition to mouse modes, it would be nice if adding map formats used the manager/provider protocol.

[Eric Pettersen]

Another manager/provider conversion: double-click select context menu registration

[Zach Pearson]

After optimizing DICOM and Segmentations I was inspired to take a look at what was being done during startup and think about how that work might be reordered to increase the apparent startup time (see the attached file, flamegraph.html).

It takes about 1.4 seconds to get to UI.build, which takes another second to finish, and in the way is a 250ms numpy import, 250ms to import Qt (this is PySide6, it's slightly longer with production builds because of the need to call promote_enums), 300ms to run UI.init (unavoidable, that's QApplication's initializer).

I'm not sure what a good solution looks like yet. We could use tinyarray more for small arrays to eliminate some numpy imports in geometry (which makes the compiled half of geometry complain that it needs numpy arrays) or inline BufferType somewhere to get rid of the top-level numpy import in opengl.py. At least one use of numpy looks unavoidable which is Color.init