|Summary:||Performance Degradation When Using Expressions|
|Product:||[Mono] Runtime||Reporter:||Jimmy [MSFT] <jimmy.garrido>|
|Component:||General||Assignee:||Rodrigo Kumpera <kumpera>|
|Severity:||normal||CC:||abdulkhn8, adrianknight89, adrian, akiander, alkpli, anuj.bhatia, asaf, brendan.zagaeski, ComConSam, cybrosys, Daniel.Regner, davdun, davide.mortara, david, dmitrijs.jesilevskis, emmanvazzbs, FieldstrikeMobile, frank.buckley, gpapadakis, grahamoneale, hardcodet, ibicom, ionixjunior, jonp, jurica.smircic, kan.vuduc, kasper, laemmchen, lgmaestrelli, luis.aguilera, martin.robins, me, michael, mono-bugs+monodroid, mono-bugs+mono, mono-bugs+runtime, norman.mackay, ondrej, pht, riccardo.marraghini, sbsdevx, tobias.schulz, tonholis, vargaz, v-chimuk, v-prala, v-sapaun, zverev.eugene|
|Tags:||15.2R||Is this bug a regression?:||Yes|
|Last known good build:||Xamarin.Android 188.8.131.52|
|Bug Depends on:|
|Bug Blocks:||56521, 56548, 56562|
minimal repro project
Description Jimmy [MSFT] 2017-05-11 17:56:30 UTC
Created attachment 22096 [details] repro project Users are reporting much slower performance in apps that are using the Xamarin.Forms RelativeLayout simply after updating to Xamarin.Android 7.3. This is happening on all recent versions of Xamarin.Forms, and in one report a user is also experiencing this when using Prism with Unity. I've attached a Xamarin.Forms Android project that navigates to a page that uses a RelativeLayout. I used a Stopwatch to measure how many milliseconds it took to navigate to the test page. The time difference after updating to Xamarin.Android 7.3 is visibly noticeable when using the app. I ran the tests below on Visual Studio for Mac and used the Xamarin.Forms 184.108.40.206 nightly with XamlC enabled. The issue can also be seen with Xamarin.Forms 220.127.116.11 and 2.3.5-pre2. Full debug outputs: https://gist.github.com/jimmgarrido/c34e5909985e9ff999055deb6d4a214e # Steps to Reproduce 1. Run the attached Android project 2. Press "Go to Test Page" # Test Results ## Android 18.104.22.168 ## Mono 22.214.171.124 - 2131ms - 1922ms - 1904ms - 1952ms - 1961ms avg: 1974ms ## Android 126.96.36.199 ## Mono 4.8.1 - 317ms - 52ms - 44ms - 53ms - 45ms avg: 102.2ms  https://forums.xamarin.com/discussion/comment/272622
Comment 1 Jonathan Pryor 2017-05-11 18:42:01 UTC
Obvious question: what changed between XA 7.2 and 7.3? https://github.com/xamarin/xamarin-android/compare/d15-1...d15-2 https://github.com/xamarin/Java.Interop/compare/d15-1...d15-2 https://github.com/xamarin/monodroid/compare/d15-1...d15-2 Last URL is private, and is a whopping 119460 line diff, most of which is due to file renames and "reference assembly API descriptions": > $ git diff d15-1..d15-2 --stat > ... > tools/api-diff/reference/Mono.Android.xml | 49433 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++------------------ > ... > 113 files changed, 66423 insertions(+), 15545 deletions(-) The other change between XA 7.2 and 7.3 is mono, bumping from mono 4.8 to "mono 5.0" (mono/2017-02), which is *yuuge*: https://github.com/mono/mono/compare/mono-4.8.0-branch...2017-02 Among the other changes between mono 4.8 and 2017-02 is that System.Linq.Expressions now comes from referencesource, which is implicated in the Xamarin Forums thread linked in Comment #0. An "interesting" avenue of investigation would be to take xamarin-android and "bump" it to use mono-4.8.0-branch instead of mono/2017-02, and see if the performance issue remains.
Comment 2 Philipp Sumi 2017-05-12 08:45:40 UTC
Yeah, my money would be on mono, too. We don't have RelativeLayout at all, but see a performance degradation that is so bad that the app is unusable. * Splash screen shows app quickly (Android activity) * Then the screen turns black, wait of way over a minute (could be several) while the XF app is loading. * When debugging, didn't see a single choke point, everything seems to take ages (before I attempt to even load the screen, such as IOC setups)
Comment 3 Kasper 2017-05-12 12:07:09 UTC
I started a thread on this on the Xamarin Android forum back when preview 1 was out. It might be of interest: https://forums.xamarin.com/discussion/94505/15-2-preview-1-performance-degradation As I see it, the reason is a massive slowdown on compilation of expression trees. Doing "poor man profilling" I found that the time was spend in: System.Runtime.CompilerServices.RuntimeHelpers.TryEnsureSufficientExecutionStack() in System.Linq.Expressions.StackGuard.TryEnterOnCurrentStack() in ... I'm not so sure about Mono 5, since switching to the 4.8 runtime in Preferences in Xamarin.Studio does not alleviate the problem. Maybe others can confirm this hold true for them as well?
Comment 4 Kasper 2017-05-12 12:29:37 UTC
So I downloaded Jimmy Garrido sample to subject it to a bit of poor man's profilling, and I can confirm that I see the same stack traces: System.Runtime.CompilerServices.RuntimeHelpers.TryEnsureSufficientExecutionStack() in System.Linq.Expressions.StackGuard.TryEnterOnCurrentStack() in ... To reproduce. 1. Run the attached Android project 2. Press "Go to Test Page" 3. Break the debugger 4. Take note of the stack trace (you need to expand the hidden external part) 5. Continue 6. Repeat from 3 until Test page shows on screen.
Comment 5 Jimmy [MSFT] 2017-05-12 20:01:17 UTC
@JonP I forked the xamarin-android repo and "bumped" Mono back to 4.8.0: https://github.com/jimmgarrido/xamarin-android/tree/downgrade-mono I used my local version of X.A with the project already attached and the performance issue was still noticeable. There did not appear to be a performance difference between the publicly released X.A 7.3 and my local X.A 7.3 built with Mono 4.8. I tested with X.A 188.8.131.52 as well which is the first build in the 15.2 release and this version _also_ experiences the issue. Hopefully this info will help narrow down what change may be causing this. Also, I tried different Xamarin.Forms versions to verify this is not an issue on their end. All the most recent versions experienced this performance issue when using X.A 7.3: 2.3.5-pre2 BAD 184.108.40.206 BAD 220.127.116.11 BAD 18.104.22.168 BAD 22.214.171.124 BAD
Comment 6 Hrvoje 2017-05-15 08:06:55 UTC
Same with me. Rolling back to 126.96.36.199 fixes the issue.
Comment 7 Tobias Schulz 2017-05-15 11:18:06 UTC
Any news? This basically breaks Android development for everybody.
Comment 8 Tuyen Duc Vu 2017-05-15 15:43:07 UTC
I faced the same issue. Any updates?
Comment 9 Jimmy [MSFT] 2017-05-16 00:48:01 UTC
As @JonP pointed out to me, I did not correctly downgrade Mono as mentioned in comment 5. Here is a new branch that should have Mono downgraded this time: https://github.com/jimmgarrido/xamarin-android/tree/downgrade_mono This new branch was created off the "d15-2" branch and I had to make additional changes for it to build successfully with Mono 4.8.0. ### Test Results Testing with this version of X.A 7.3 built with Mono 4.8.0 _did_ appear to resolve the issue. The time to navigate to the test page in the repro project matched the times seen when testing with X.A 7.2. I am convinced now that this is an issue in the Mono source and not X.A.
Comment 10 Kasper 2017-05-16 10:54:07 UTC
@JimmyGariod & @JonP Is it possible to "correctly" downgrade Mono to 4.8 without downgrading Xamarin.Android to 7.2 currently?
Comment 11 Jonathan Pryor 2017-05-16 17:00:00 UTC
@Kasper: *Most* of Xamarin.Android doesn't "care" about which Mono version it's running on, and thus most of it could continue using Mono 4.8. Unfortunately, "most" is not "all"; the primary change between Mono 4.8 and 5.0 is support for Portable PDB files, which spreads to various places (app packaging, deployment, on-device app startup...) With Portable PDB now being "a thing," and a near certainty that more and more NuGet packages will be using and distributing Portable PDB files going forward, that's a *large* feature to be missing, unless you don't care about debugging at all. This largely means that Xamarin.Android *itself* reverting to Mono 4.8 is not considered to be viable. Which is to say, if you needed/wanted to, you should be able to take @Jimmy's xamarin-android/downgrade_mono branch and use that to build your app. It just won't be "pretty". Related: https://github.com/xamarin/xamarin-android/blob/master/Documentation/UsingJenkinsBuildArtifacts.md We will have the class library team look into optimizing this code path.
Comment 12 Jimmy [MSFT] 2017-05-16 20:26:43 UTC
Created attachment 22213 [details] minimal repro project I am attaching a new, minimal Android (non-Forms) project that reproduces the issue by executing an expression tree. # Steps to Reproduce 1. Run the attached project on an Android device 2. Press "Click Me" 3. The debug output will show the milliseconds elapsed using a Stopwatch # Test Results ## X.A 7.2 / Mono 4.8 - 210 ms - 20 ms - 20 ms - 21 ms - 20 ms ## X.A 7.3 / Mono 5.0 - 1627 ms - 1412 ms - 1421 ms - 1416 ms - 1421 ms ## X.A 7.3 / Mono 4.8 - 333 ms - 29 ms - 26 ms - 30 ms - 28 ms
Comment 13 Jimmy [MSFT] 2017-05-16 20:30:56 UTC
*** Bug 56123 has been marked as a duplicate of this bug. ***
Comment 14 Philipp Sumi 2017-05-16 21:07:06 UTC
Apart from the current performance issue with Mono 5.0: Do you also have an idea about the 50% performance degradation you observed in X.A 7.3 / Mono 4.8 compared to 7.2?
Comment 15 Alexander Köplinger [MSFT] 2017-05-16 21:24:44 UTC
I quickly tried the sample code from #c12 in a console app and I'm seeing better numbers in Mono 188.8.131.52 compared to 5.0.
Comment 16 Tobias Schulz 2017-05-16 21:26:20 UTC
How much better?
Comment 17 Alexander Köplinger [MSFT] 2017-05-16 21:57:09 UTC
(I increased the counter to 20000) OSX mono64 4.8.1: 1467ms OSX mono64 184.108.40.206: 1547ms OSX mono64 220.127.116.11: 1283ms Linux mono64 18.104.22.1684: 1323ms Linux mono64 22.214.171.124: 21254ms Linux mono64 126.96.36.1992: 20625ms Interestingly I don't see the huge performance degradation on OSX Mono 5.0, but it *is* there on Linux and is not yet fixed in later builds. The Linux measurements were done using a Docker container on the same MacBook.
Comment 18 Jimmy [MSFT] 2017-05-16 22:37:17 UTC
Created attachment 22217 [details] console app The results below are from the console app I'm attaching. I don't have a Linux setup to compare with, but I am seeing a marginal difference on macOS as mentioned in comment 17. ## macOS Mono 5.0 Run 1: 1850 ms Run 2: 1812 ms Run 3: 1853 ms Run 4: 1836 ms Run 5: 1861 ms ## macOS Mono 4.8 Run 1: 1742 ms Run 2: 1766 ms Run 3: 1760 ms Run 4: 1751 ms Run 5: 1769 ms
Comment 19 Brendan Zagaeski (Xamarin Support) 2017-05-16 23:59:40 UTC
*** Bug 56490 has been marked as a duplicate of this bug. ***
Comment 20 Zoltan Varga 2017-05-17 01:13:07 UTC
I can reproduce the slowdown, but only on linux, osx performance is about the same.
Comment 21 Tobias Schulz 2017-05-17 03:22:15 UTC
I tried to figure out since when this bug exists, but the mono-snapshot packages are only available since March 1... The code must have been introduced in February, January or December. Seriously, that is a major fuckup. How did nobody notice this?
Comment 23 Tobias Schulz 2017-05-17 17:36:36 UTC
Nice! Now we need a hotfix for xamarin.android and VS 2017.2.xamarin.android
Comment 24 Craig Johnson 2017-05-17 17:38:12 UTC
Please push change immediately to Xamarin.Android on Visual Studio 2017, both to the 15.3 preview and to the 15.2 production release.
Comment 25 Brendan Zagaeski (Xamarin Support) 2017-05-17 18:43:22 UTC
> Please push change immediately To provide a little context on timing, integrating the change into Xamarin.Android in Visual Studio 2017 will take a little bit more time. There is a tentative round of fixes for Visual Studio 2017 due out this week, but since the candidate change from Comment 22 is new as of today, that change will have to catch the next bug fix release, possibly within the next week or so. The Xamarin team will keep this bug up-to-date with information about the release location of the fix as it becomes available. Depending on the testing results of the candidate change from Comment 22 with internal development builds, it might also be possible to provide temporary packages for Visual Studio 2017 until the next full Visual Studio 2017 update is available.
Comment 26 Philipp Sumi 2017-05-17 18:53:24 UTC
Any chance that hotfixes will be aligned with bug #56275? I'm currently stuck in developer hell between restarting VS all the time, and then waiting for ages for the app to actually do something. If those get fixed independently, I'd hate to revert one bugfix with another.
Comment 27 Tobias Schulz 2017-05-17 18:58:25 UTC
The current "stable" version of Visual Studio 2017 is basically useless for Android App development without this fix. If you can't integrate it in the next VS update, please provide a hotfix .vsix on releases.xamarin.com.please
Comment 28 Brendan Zagaeski (Xamarin Support) 2017-05-17 19:04:30 UTC
> Any chance that hotfixes will be aligned with bug #56275 It is certainly possible, but it will be necessary to wait for a little while longer to see what further information about Bug 56275 unfolds over the next few days. In particular, there is not yet a precisely defined candidate fix for Bug 56275.
Comment 29 Philipp Sumi 2017-05-17 19:08:55 UTC
You can imagine that nobody wants to wait a little longer. I was rather thinking along the lines of a second hotfix containing the first one ;)
Comment 30 Craig Johnson 2017-05-17 19:57:54 UTC
Brendan, I appreciate there may be difficulties but this is an absolute breaking change which renders all Android development impossible and Visual Studio 2017 is not conducive to downgrading. A temporary package would be fine - the main point is to please make it possible to actually build usable Android applications independent of other bugs that, while painful, do not actually cause a complete down situation. I can't imagine any stable release of Xamarin has ever been so fundamentally broken.
Comment 31 Brendan Zagaeski (Xamarin Support) 2017-05-17 20:07:46 UTC
To be clear, _if_ the candidate change from Comment 22 does indeed help resolve the issue in local testing once it has been integrated into development builds (as soon as possible), it will be made available as soon as possible to users in whatever way is possible. In Comment 25, I wanted to make it clear that the overall Visual Studio 2017 release process has a certain cadence, and I wanted to give some pre-warning that the _exact_ new build of Visual Studio 2017 that is tentatively planned to be made available this week will _not_ yet include the fix. I wouldn't classify any of this information in particular as "difficulties." It is aimed at presenting facts of how a change in a product can be propagated into various kinds of builds in the hopes that that might be helpful for general context. Hope that helps! Best, Brendan Xamarin Support
Comment 32 Craig Johnson 2017-05-17 20:24:01 UTC
Brendan, thank you for the clarification on why this fix may take a bit longer to find its way into Visual Studio itself. As you suggest, I will monitor this bug for release information on whatever fix becomes available.
Comment 33 Jimmy [MSFT] 2017-05-17 23:37:29 UTC
*** Bug 56441 has been marked as a duplicate of this bug. ***
Comment 34 Pratik Lad 2017-05-18 09:28:19 UTC
Following are the step I followed to verify this bug 1. Open Visual Studio Enterprise 2017 for MAC 2. Run the project which was attached in the bug on an Android device 3. Press "Click Me" 4. Captured the debug output Observed the following The milliseconds elapsed showed For Mono 188.8.131.52 / Xamarin.Android Version 184.108.40.206 Milliseconds elapsed: 2653 Milliseconds elapsed: 2640 Milliseconds elapsed: 2653 Milliseconds elapsed: 2639 Milliseconds elapsed: 2671 Milliseconds elapsed: 2644 Milliseconds elapsed: 2660 For Mono 220.127.116.11 / Xamarin.Android Version 18.104.22.168 Milliseconds elapsed: 209 Milliseconds elapsed: 28 Milliseconds elapsed: 29 Milliseconds elapsed: 22 Milliseconds elapsed: 19 Milliseconds elapsed: 21 Milliseconds elapsed: 19 Observe the clear difference between output of Xamarin.Android Version 22.214.171.124 and 126.96.36.199 Please let me know if anything else is required
Comment 35 Brendan Zagaeski (Xamarin Support) 2017-05-18 15:59:10 UTC
## Note to users watching this bug For a quick clarification, Comment 34 is verification attempt based on an in-progress development build "Xamarin.Android 188.8.131.52". That build has not yet been published in a public location, but that experimental build or another experimental build that includes that fix will be provided as soon as possible for additional user verification of the candidate change.
Comment 36 Chiranjib Mukherjee 2017-05-19 12:17:01 UTC
@Brendan Zagaeski Please do let us know when the desired build is ready so that the team here can verify the same on our end. thanks
Comment 37 Aaron Kiander 2017-05-19 19:42:29 UTC
Agreed - please let us know when we can get this fix because this is negatively impacting our release which *was* scheduled for today but now has moved to next week.
Comment 38 Brendan Zagaeski (Xamarin Support) 2017-05-19 20:56:45 UTC
## Status update The candidate change from Comment 22 has now been published to the Stable updater channel for Mac only for the moment  to provide the earliest possible availability of the candidate fix on Mac while the corresponding Windows builds are being finalized. As mentioned on , the corresponding Windows builds are in progress for finalization. The tentative goal will be to have the Windows versions available within no more than a couple business days. I will keep the status up-to-date as the builds and integration move forward in case there are any unexpected hiccups, and I will advise if builds suitable for distribution become available sooner (for example, before they are published via the updaters).  https://releases.xamarin.com/stable-release-15-2-hotfix-xamarin-android-mac-only/
Comment 39 Ione Souza Junior 2017-05-19 21:35:28 UTC
Great job, works perfectly! Thank you very much!
Comment 40 Craig Johnson 2017-05-19 22:58:27 UTC
Thank you for the update. Awaiting the Windows fix as per your comment 38.
Comment 41 Kasper 2017-05-20 17:14:14 UTC
Thanks for the fix. Would it be possible to update Xamarin.Android to 184.108.40.206 in the Alpha channel as well, so that we can still experiment with the live player?
Comment 42 Adrian Grigore 2017-05-20 23:29:18 UTC
For me, this bug caused my app to suddenly take about 3 Minutes just to start. It's very easy to spot this issue without doing any performance profiling. Therefore I'm quite surprised this bug made it into a stable release build. While it's easy the spot the bug, the effect is detrimental to my productivity. It took me a few hours to realize it's not my code's fault and it will hurt my productivity even further until a fix is finally available. May I suggest that you also add an integration test to your test suite that monitors performance of compiled code inside an emulator? It would probably have avoided distributing a bug of such magnitude.
Comment 43 goneale 2017-05-22 01:25:26 UTC
Looking forward to the Windows fix! Has halted our production deployments.
Comment 44 goneale 2017-05-22 01:37:58 UTC
Could I also propose along with Stable, Alpha, Beta channels perhaps a Previous channel which could take us easily back to the previous build which would allow developers to rapidly diagnose if a problem relates to their own code or the new update, it would also crucially allow us to revert so we can continue production.
Comment 45 Michael Rumpler 2017-05-22 08:48:28 UTC
Feature requests should be handled in UserVoice. Somebody already posted a request for that on https://xamarin.uservoice.com/forums/144858-xamarin-platform-suggestions/suggestions/19263328-allow-installing-older-versions-of-xamarin-in-visu
Comment 48 Brendan Zagaeski (Xamarin Support) 2017-05-23 15:29:16 UTC
## Bookkeeping note Comment 46 and Comment 47 are not relevant to users, so I have marked them as non-public to keep the public-facing bug report focused on the information that is relevant to users watching this bug.
Comment 49 Adrian Grigore 2017-05-24 19:06:07 UTC
It's been a few hours since this bug was set to RESOLVED / VERIFIED. It's also been over 2 business days (Brendan Zagaeski's original estimation of when this will be resolved). When can we expect the windows build of the hotfix?
Comment 50 Aaron Kiander 2017-05-24 19:53:02 UTC
This ticket says Status Verified Fixed, but I don't see this fix available from the updates section in Visual Studio 2017 (windows). This is has had a major impact on our team and our schedule - can someone please advise how we can install this fix on windows?
Comment 51 goneale 2017-05-26 01:34:43 UTC
15 days since this issue was reported. A lot of us anxiously awaiting that Windows fix or a way to revert a version. Please advise ETA.
Comment 52 Brendan Zagaeski (Xamarin Support) 2017-05-26 06:15:23 UTC
## Visual Studio 2017 The fix for this issue has been added to the next upcoming Visual Studio 2017 update in the Visual Studio Installer. The most direct workaround until that release would be to install Visual Studio 2017 version 15.0 (see https://www.visualstudio.com/vs/older-downloads/) to get back to Xamarin.VisualStudio 4.3.0 with Xamarin.Android 7.1.0. My understanding is that the timeline for the next Visual Studio 2017 update is as soon as possible, but unfortunately I in Xamarin support don't have more insight about the updated timeline than that. One potential way to apply the fix to Visual Studio 2017 in the mean time is the following (with a warning that I have only experimented with this briefly on one Android 6.0 armeabi-v7a device using the particular test project from Comment 0). 1. Extract the Visual Studio 2015 220.127.116.115 installer (from "Download links" on ) in a cmd.exe command prompt. (You can optionally customize the TARGETDIR.) msiexec /a Xamarin.VisualStudio_18.104.22.1685.msi /qb TARGETDIR=C:\Temp\Xamarin 2. Move the following directory from your existing Visual Studio 2017 installation to a backup location: %VSINSTALLDIR%\MSBuild\Xamarin\Android\lib By default the full expanded path for this (for example in a Developer Command Prompt) will be one of the following, depending on Visual Studio edition: > C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\Xamarin\Android\lib > C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\Xamarin\Android\lib > C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\Xamarin\Android\lib 3. Now move the corresponding "MSBuild\Xamarin\Android\lib" directory from the extracted installer into "%VSINSTALLDIR%\MSBuild\Xamarin\Android\lib" as a replacement. 4. Follow steps 2 and 3 once more to replace: %VSINSTALLDIR%\Common7\IDE\ReferenceAssemblies\Microsoft\Framework\MonoAndroid ... with the "Reference Assemblies\Microsoft\Framework\MonoAndroid" directory from the extracted installer. 5. Similarly, move all of the "*DebugRuntime*" files out of "%VSINSTALLDIR%\MSBuild\Xamarin\Android" to a backup location, and move all of "*DebugRuntime*" files from the extracted installer's "MSBuild\Xamarin\Android" directory in as replacements. 6. Close and reopen Visual Studio, and clean, rebuild, and redeploy the Android app project. ## Links >  https://kb.xamarin.com/customer/portal/articles/1699777-older-downloads ## Visual Studio 2015 For Visual Studio 2015 users, an installer is available on the Xamarin updater channels that includes the fix for this bug, or it is also possible to downgrade to Xamarin.VisualStudio 4.4.0 by following the steps on .
Comment 53 Giorgos Papadakis 2017-05-26 11:38:47 UTC
That is a great problem. The only solution that i can find for the future is move all my xamarin development to a mac as i believe the update rollouts it is handled my xamarin. My boss understands by our clients not as we are obligated by contracts to push in beta channels new versions. We are entering 3rd week, ready to run of the cliff.
Comment 54 Brendan Zagaeski (Xamarin Support) 2017-05-26 16:18:10 UTC
*** Bug 56548 has been marked as a duplicate of this bug. ***
Comment 55 adrianknight89 2017-05-27 13:40:08 UTC
Brendan, Can you update this thread when the next Preview version of VS 2017 comes out? I'm using 15.3 (26510.0) now, and I'm assuming it will be the next after this. Thanks.
Comment 56 Brendan Zagaeski (Xamarin Support) 2017-05-30 20:06:10 UTC
## Status update for Visual Studio 2017 The candidate fix for this bug report (from Comment 22) is now included in today's Visual Studio 2017 version 15.2 (26430.12) update (https://www.visualstudio.com/news/releasenotes/vs2017-relnotes ). (2017-05-30) Visual Studio 2017 version 15.2 (26430.12) Includes Xamarin.VisualStudio IDE extension version: 22.214.171.1246 (1be4f0c) If any user still hits a similar behavior consistently after updating to Visual Studio 2017 version 15.2 (26430.12) or higher (or Xamarin.VisualStudio 126.96.36.1995 or higher in Visual Studio 2015 and below), please create a new bug report. Be sure to mention any details for the remaining problematic scenario that might differ from the original scenario described in this bug report in Comment 0. Thanks in advance!
Comment 57 Brendan Zagaeski (Xamarin Support) 2017-05-30 20:13:10 UTC
## Status update for Visual Studio 2017 Preview > update this thread when the next Preview version of VS 2017 comes out As an additional status clarification, the candidate fix from Comment 22 is now included in the Visual Studio 2017 version 15.2 (26430.12) from the _release_ channel, but it is not yet included in the current Visual Studio 2017 _Preview_ version 15.3 (26510.00 - Preview) from May 11. By default it will indeed be included in the next Visual Studio 2017 Preview version of 15.3. I will plan to update the bug once more when a new preview version with the fix is published.
Comment 58 Philipp Sumi 2017-05-31 00:22:01 UTC
Trying out the latest 15.2, and the app is usable again. However: Is it just me, or is the performance still clearly below what we had with 15.1? I'm still getting a black screen (for a much shorter period though) while loading my app, and overall startup time (navigation and retrieving data) is clearly slower.
Comment 59 goneale 2017-05-31 00:34:50 UTC
Philipp, I will be testing soon on the new VS 15.2. As Brendan stated, we should create a new bug report if we see any exhibiting behavior of performance problems once more.
Comment 60 Hrvoje 2017-05-31 07:06:22 UTC
Philip Summi, preview is 15.3, not 15.2. Brendan, I'm not happy with this new concept of installation introduced in Visual Studio 2017, having Preview as separate installation. It requires additional disk space, and if I have limited disk space (e.g. SSD disk), we need to uninstall VS completely, then install Preview, and if we are not satisfied, perform rollback using the same steps which requires much more time then before. For me, the previous option to be able to update Xamarin (and even swich channel to beta or alpha) using Visual Studio was much better update option. Since cross-platform development tools itself require much more attention than desktop, or web development tools, updates should be more often than slow VS updates, and this is the reason why we should have the option to update Xamarin separately of Visual Studio.
Comment 61 martin.robins 2017-05-31 14:53:44 UTC
I have just installed VS2017 15.2 (26430.12) and after cleaning and rebuilding my project I have found it to be significantly faster that it was before the update (previous start-up time was around 30+ seconds whereas now it is less than 10, opening a new form is near instant whereas it was taking up to 10 seconds the first time - though near instant for subsequent instances of the same form). I am not however using RelativeLayout though I am using both Prism and Unity.
Comment 62 Brendan Zagaeski (Xamarin Support) 2017-05-31 17:13:08 UTC
> concept of installation Note that this bug report is focused on the specific technical problem described in Comment 0. For broader discussions about installation features, UserVoice is one place to surface information to the Xamarin team. For example: https://xamarin.uservoice.com/forums/144858-xamarin-platform-suggestions/suggestions/19263328-allow-installing-older-versions-of-xamarin-in-visu Thanks!
Comment 63 Jon Douglas [MSFT] 2017-06-23 19:20:39 UTC
*** Bug 56562 has been marked as a duplicate of this bug. ***