Bug 26590 - Building unchanged project is very slow
Summary: Building unchanged project is very slow
Status: IN_PROGRESS
Alias: None
Product: Android
Classification: Xamarin
Component: MSBuild ()
Version: 4.20.0
Hardware: PC Windows
: Normal normal
Target Milestone: ---
Assignee: dean.ellis
URL:
Depends on:
Blocks:
 
Reported: 2015-01-30 05:15 UTC by Paul Read
Modified: 2016-05-11 12:29 UTC (History)
5 users (show)

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


Attachments
Diagnostic log output for a 're-run' of an unchanged project. (960.20 KB, text/plain)
2015-02-10 17:12 UTC, Paul Read
Details


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 for Bug 26590 on Developer Community or GitHub if you have new information to add and do not yet see a matching new report.

If the latest results still closely match this report, you can use the original description:

  • Export the original title and description: Developer Community HTML or GitHub Markdown
  • Copy the title and description into the new report. Adjust them to be up-to-date if needed.
  • Add your new information.

In special cases on GitHub you might also want the comments: GitHub Markdown with public comments

Related Links:
Status:
IN_PROGRESS

Description Paul Read 2015-01-30 05:15:23 UTC
On going PITA issue.
Bug 1569 says issue resolved yet continues to slow down my development

Steps to produce
Create Android Xamarin forms portable 
Buid and deploy to device
Shift F5 to stop it
(Without making any code edits) F5 to run again
Notice the app does not run again immediately instead a rebuild and deploy happens wasting valuable time
Comment 1 Udham Singh 2015-02-02 08:08:55 UTC
I have checked this issue with the help of instructions given in bug and getting the reported behaviour.

Screencast : http://www.screencast.com/t/HoquAt5y

Environment Info : 

=== Xamarin Studio ===

Version 5.7.1 (build 16)
Installation UUID: 1acc211c-3883-4e33-b4d2-ad3b5d55c2c8
Runtime:
	Microsoft .NET 4.0.30319.18449
	GTK+ 2.24.22 (MS-Windows theme)
	GTK# 2.12.26

=== Xamarin.Android ===

Version: 4.20.0 (Business Edition)
Android SDK: D:\Backup_OldMachine\D Drive\SDK\android-sdk
	Supported Android versions:
		1.6    (API level 4)
		2.1    (API level 7)
		2.2    (API level 8)
		2.3    (API level 10)
		3.1    (API level 12)
		4.0    (API level 14)
		4.0.3  (API level 15)
		4.1    (API level 16)
		4.2    (API level 17)
		4.3    (API level 18)
		4.4    (API level 19)
		4.4.87 (API level 20)
Java SDK: C:\Program Files\Java\jdk1.7.0_67
java version "1.7.0_67"
Java(TM) SE Runtime Environment (build 1.7.0_67-b01)
Java HotSpot(TM) 64-Bit Server VM (build 24.65-b04, mixed mode)

=== Build Information ===

Release ID: 507010016
Git revision: f12fcaf4707ab436bee2df6263eb5333197b262c
Build date: 2015-02-01 19:17:02-05
Xamarin addins: f7b7d34419c9ec24501bfa7c658e80a6305613e0

=== Operating System ===

Windows 6.2.9200.0 (64-bit)
Comment 2 Paul Read 2015-02-10 09:09:14 UTC
Please can this issue be given a high priority - it must surely effect many, many XS users contributing to much global productivity time loss, unnecessary energy consumption, extra CO2 emissions and global warming. As well as additional annoyance and boredom build up in the users, possibly leading to pre-mature death of user and/or additional violence against computers.

Ta!
Comment 3 Mikayla Hutchinson [MSFT] 2015-02-10 16:08:02 UTC
It's not rebuilding. It's doing an incremental build, which should determine that everything is up to date and skip actually changing anything. In theory this should be extremely fast. If it's not, then it would be interesting to see a diagnostic build log from one of these builds so we can determine why it's slow.

We do have a feature coming up in a future release that will improve this - Visual Studio style "fast build check". This is a fast-but-imprecise check that can be used to determine whether to automatically trigger a build when you run/debug. We could probably add a similar check for packaging/deploying the app.
Comment 4 Greg Munn 2015-02-10 16:50:18 UTC
Paul, could you watch the screencast in comment 1 and verify that what it shows is what you are seeing. If it's different, could you show / explain in what way and what project options you have (fast deployment, shared runtime etc).

As Michael indicated, we do have a feature coming up which will bypass a lot of these checks if the IDE thinks nothing has changed, but there are still places to improve things once the build has been done and it about to launch the app and we are looking into this.
Comment 5 Paul Read 2015-02-10 17:02:59 UTC
Yes about the same as the screencast. ie. I stop my app, and then press run and it takes circa 10 secs before the app runs again. While my expectation it should be near instant.

Output from the package console:
Checking myTAS for updates...
0 updates found.
Checking myTAS.Android for updates...
0 updates found.

Packages are up to date.


Output from 'Deploy to device':

Detecting installed packages

Waiting for packaging to complete

Synchronizing assemblies

Deployment completed



Those 10 seconds are a long time, if like me you do a lot of short runs trying to understand/debug (aka learn) C#, Xamarin Forms, etc etc


I really really look forward to the new fast check!
Comment 6 Mikayla Hutchinson [MSFT] 2015-02-10 17:05:19 UTC
Is the slowest part the 'Deploy to device' or the build?

You can find the build log in the errors pad, and you can enable diagnostic verbosity in preferences (be aware that diagnostic verbosity itself slows the build a little).
Comment 7 Paul Read 2015-02-10 17:12:21 UTC
Created attachment 9758 [details]
Diagnostic log output for a 're-run' of an unchanged project.

Diagnostic log output for a 're-run' of an unchanged project.  I note it says 4000mS at the end but feels far longer.  Build and packaging seem the longer bit going by the output in the top of the XS window
Comment 8 Paul Read 2015-02-10 17:13:24 UTC
This is using X Android Player running on same physical PC. Windows 8 (high perf machine)
Comment 9 Mikayla Hutchinson [MSFT] 2015-02-10 17:27:52 UTC
3461 ms for ScanAssemblies on an unchanged project looks way too expensive. Moving this over to the build code.

The build looks to be about 5 seconds, assuming packaging is around 5 seconds too, for your total of 10.
Comment 10 Paul Read 2015-02-11 03:51:31 UTC
Status = IN_PROGRESS

Yea! :-)
Comment 11 Paul Read 2015-02-16 05:27:39 UTC
I also note that if I untick the option  Projects->Build->Build solution before running, it incorrectly gives this warning:

'The project you are executing has changes done after the last time it was compiled. The debug information may be outdated. Do you want to continue?'

when NO changes have occurred.

(I added this to this bug as the Testers will need to verify these build settings work correctly with the resolution of the main bug I reported here)
Comment 12 Paul Read 2015-05-21 10:28:13 UTC
It's getting better, thanks for working on this
Comment 13 dean.ellis 2015-05-21 10:50:13 UTC
Np Paul. more changes on the way :)