Bug 30539 - Slow to start due to updating packages
Summary: Slow to start due to updating packages
Alias: None
Product: Xamarin Studio
Classification: Desktop
Component: Project Management ()
Version: 5.9
Hardware: PC Mac OS
: Low enhancement
Target Milestone: master
Assignee: Bugzilla
Depends on:
Reported: 2015-05-28 09:15 UTC by Michael Bevin
Modified: 2017-05-12 20:12 UTC (History)
4 users (show)

Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:

Description Michael Bevin 2015-05-28 09:15:33 UTC
It takes 60+ seconds on start when open solution, after loading is completed, with 'Checking for package updates...' (or sometimes it also takes time 'restoring' packages or loading, but right now its just saying loading...), for our project (which makes use of a reasonable number of packages). 

While it is doing this, some things do work, but some things like i.e. cmd-. search (which typically I want to do right away to jump to whatever source-file I'm interested in) doesn't appear to work until it is complete.
Comment 1 Matt Ward 2015-05-29 11:49:35 UTC
Checking for package updates is done on a separate background thread so that should not affect interaction with the IDE.

Loading and package restore is done on the background dispatcher thread which could have an impact on other parts of the IDE that do background tasks using this thread.

You can disable the check for package updates and package restore on solution open in Preferences - NuGet. Try that and see if it makes any difference.
Comment 2 Lluis Sanchez 2015-06-03 04:34:44 UTC
The global search uses the type system, and loading the type system may take a few seconds for big solutions. So it is normal if the global search doesn't give immediate results just after loading a solution.
Comment 3 Michael Bevin 2015-06-05 15:42:36 UTC
@Matt - thanks for that tip re the Preferences - that does indeed help remove the problem for me.

@Lluis - its not the loading of the type system that is the issue, but that the loading of the type system (or in any case, the ability to perform search) is blocked behind the updating of packages, which appears to be capable of taking an order of magnitude or two longer than just like loading the type system. 

Hence it would seem sensible to not make the ability to perform global search (+ other critical things like i.e. building+running the app) be stuck behind non-essential but potentially extremely slow actions like checking for package updates and other such tasks which (perhaps partly due to their dependence on network usage) can take large amounts of time, and are nore really such critical tasks that should block these other more critical things.
Comment 4 Lluis Sanchez 2015-06-05 16:30:12 UTC
There isn't any kind of dependency between the type system and the package manager, they operate independently. I can open a solution with many nuget references and search starts working long before the package manager ends checking for updates.

So, if the package update check takes for you 60s, do you mean that the search result pops up just after update check finishes? If that's the case, then we'll have to do some digging, since it is not normal. The type system may take a while to load, but not as much as 60s.
Comment 5 Kirill Osenkov 2017-05-12 20:12:19 UTC
We're resolving this issue for now but please feel free to open a new bug if you're still running into problems. Thanks.