-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Time Spent to Cold Launch Napari Intereface #26
Comments
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. |
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 |
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. |
Short view in my case:
Topic needs longer investigation. screenshot is from $ python -X importtime start_speed.py 2> import.log
$ tuna import.log |
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). |
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). |
Oh, nice! It would be interesting to see the |
@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? |
(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) |
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
(Use this option when you feel there’s a challenge to be solved, but you’re curious about what the experience should be — may involve research studies to understand challenges/opportunities for design)
(If choosing this level alone, it means that the content to be mocked up and its organization is already known and specified)
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?
The text was updated successfully, but these errors were encountered: