napari / packaging

6 stars 9 forks source link

Time Spent to Cold Launch Napari Intereface #26

Open spikeliu opened 2 years ago

spikeliu commented 2 years ago

Overview of design need

I've tried to install napari by using conda or download the package from the release page (exe version, not the msi version), and in both way, it takes sereral seconds to launch it for the first time (should I call it cold start?) after my machine (Windows system) is booted (so there is no relevant cache in the RAM). My computer has a Intel i9-12900K CPU, with 64GB RAM and a RTX 3090 GPU. The way I launched it was just type in napari in the virtual env or double click the icon. I also tried the same thing on some of my colleagues' machine, and they all appears to take similar time. Is there a way to speed things up or is there a plan to make a more effcient pre-compiled version of it?

What level of design is needed? (Choose all that apply)

This section may be updated by the designer / UX researcher working on this issue

Is design a blocker?

If selecting Yes, how much design input is needed to unblock engineering? For example, is a full, final visual design needed, or just a recommendation of which conceptual direction to go?

spikeliu commented 2 years ago

I just tried the msi version, the first time I may take several minutes to lanuch the program. But after that, no matter I restart the machine or not, it only takes around 4 seconds to launch it. But there is also a problem, I can not specify the install location with the msi installer, which may not be very convenient.

alisterburt commented 2 years ago

Thanks for the report @spikeliu - startup time on first run is definitely something I've come across and agree we would ideally fix but I'm not aware of any immediate plans. There has been some previous discussion around import times at napari/napari#758 napari/napari#2121 napari/napari#2325 and we have a lazy import strategy in place to mitigate these things, this strategy will likely become standard in the ecosystem with PEP690 🙂

cc'ing @jaimergp and @goanpeca for the install location with the msi installer - is this something that would be easy to add? Request seems reasonable and I'm not sure where the default location is

Czaki commented 2 years ago

Hi @spikeliu. One of the information that is missed in your issue is information about the hard drive in your machine. One of the blocking things is loading data from the drive. So if you install conda a slower drive than msi installer (that is also conda based) then it may impact load time.

Also, there is a question about used AV software. Many AV slowdown first application startups.

But of course, we should speed up napari startup.

Czaki commented 2 years ago

Zrzut ekranu z 2022-07-04 14-35-00

Short view in my case:

  1. Octotree has impact, and maybe could be removed.
  2. Import Dask has impact
  3. scipy.stats has impact, but its import is required. Base on comments from napari._lazy module https://github.com/napari/napari/blob/d2bea0b21e264fa87ad8073ceb135ebb6de6a9ec/napari/_lazy.py#L37-L42

Topic needs longer investigation.

screenshot is from tuna app created using:

$ python -X importtime start_speed.py 2> import.log
$ tuna import.log
jaimergp commented 2 years ago

The MSI installers are built with Briefcase, packaged from PyPI, and are scheduled for deprecation. The EXE installers are built with constructor, use conda packaging, and allow to select the target location.

It would be surprising to see any time differences between the conda-based installations (either an environment manually created by the user, or the one provided by the installer).

spikeliu commented 2 years ago

I tried to launch the MSI and EXE version on a SSD drive, MSI version took ~4s, and EXE version ~18s (~13s for further re-launch).

jaimergp commented 2 years ago

Oh, nice! It would be interesting to see the tuna timings for both. We'll see what we can do about it on Windows.

jni commented 2 years ago

@Czaki my impression reading the importtime plot is that octree takes up about 4% of the initial launch time? Which doesn't seem like a high priority to me? Or am I misreading that.

Regarding scipy.stats, I don't think we ever understood why this affected things — it might be time to experiment with removing it again? I expect the issue had to do with weird binary incompatibility errors that may be much more rare now that everyone is using cibuildwheel.

I'd also like to get rid of the IPython console imports and delay those until someone pushes the console button — in fact I thought we were already doing that? Or do you have the console permanently open in your settings?

liaprins-czi commented 2 years ago

(Just re-assigned to Lisa and Isabela, as they'll be more focused on the napari viewer interface, and will have more context than me! But feel free to ask me specifically if anyone think's I'd be able to weigh in on something due to past work I've done on the viewer, etc)