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.

[pett]

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.

[pett]

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

[Tom Goddard]

On my Mac Studio M2 Ultra ChimeraX displays its user interface in about 1 second from the time I click the dock icon after it has been run once so everything is in disk cache. That is an acceptable speed. Of course faster is better. But it is not reasonable to change numpy for tinyarrays just for startup speed. From Zach's preceding comment it seems Qt is most of the startup time, but numpy also contributes. I'm not sure though what the total start time until GUI appears for Zach, sounds like it may be 2.4 seconds, of which only 0.8 seconds was accounted for (.25 numpy, .25 import Qt, .3 UI.init). While it may be possible to avoid importing numpy at startup that seems like a losing battle, since any tool that does an init may import numpy. If Qt really accounts for less than a quarter of startup time then there is not a great opportunity to speed up the Qt part. But where does all the other time go? Importing 1000 Python files?

At any rate, I'd say if the 1 second startup time is similar on Windows and Mac with SSD/NVMe drive and there is no single big contributor that could significantly change that, then probably we have enough startup optimization. What might be useful though in that case is a capability to report start-up time hogs. For instance if I install ISOLDE and say it did some custom inits and slowed by 1 second startup down to 2 seconds, I would probably never figure out why startup slowed down unless some code looked for and notified me about tools that were slowing the startup. I would say this is a pretty low priority though.