locked
15-2-preview-1 performance degradation RRS feed

  • Question

  • User2593 posted

    Hi

    Am I the only one who sees massive performance degradation when updating from stable to the beta channel?

    Startup time of the app I'm working on jumps a factor 10. I'm using Prism with Unity, which uses expression trees, and a quick sampling of stack traces tells me that evaluation of expression trees has gone through the floor.

    It is not just Unity. Relative Layout in XF, and ReactiveUI, also uses expression trees, and they suffer as well.

    A typical example of a sampled stacktrace:

    System.Runtime.CompilerServices.RuntimeHelpers.TryEnsureSufficientExecutionStack() in 
    System.Linq.Expressions.StackGuard.TryEnterOnCurrentStack() in 
    System.Linq.Expressions.Compiler.StackSpiller.RewriteExpression( node,  stack) in 
    System.Linq.Expressions.Compiler.StackSpiller.RewriteUnaryExpression( Parameters) in 
    System.Linq.Expressions.Compiler.StackSpiller.RewriteExpression( Parameters) in 
    System.Linq.Expressions.Compiler.StackSpiller.ChildRewriter.Add( Parameters) in 
    System.Linq.Expressions.Compiler.StackSpiller.RewriteMemberAssignment( Parameters) in 
    System.Linq.Expressions.Compiler.StackSpiller.RewriteAssignBinaryExpression( Parameters) in 
    System.Linq.Expressions.Compiler.StackSpiller.RewriteExpression( Parameters) in 
    System.Linq.Expressions.Compiler.StackSpiller.RewriteBlockExpression( Parameters) in 
    System.Linq.Expressions.Compiler.StackSpiller.RewriteExpression( Parameters) in 
    System.Linq.Expressions.Compiler.StackSpiller.RewriteConditionalExpression( Parameters) in 
    System.Linq.Expressions.Compiler.StackSpiller.RewriteExpression( Parameters) in 
    System.Linq.Expressions.Compiler.StackSpiller.RewriteBlockExpression( Parameters) in 
    System.Linq.Expressions.Compiler.StackSpiller.RewriteExpression( Parameters) in 
    System.Linq.Expressions.Compiler.StackSpiller.RewriteExpressionFreeTemps( Parameters) in 
    System.Linq.Expressions.Compiler.StackSpiller.Rewrite<System.Func<Microsoft.Practices.ObjectBuilder2.IBuilderContext,object>>( Parameters) in 
    System.Linq.Expressions.Expression<System.Func<Microsoft.Practices.ObjectBuilder2.IBuilderContext,object>>.Accept( Parameters) in 
    System.Linq.Expressions.Compiler.StackSpiller.AnalyzeLambda( Parameters) in 
    System.Linq.Expressions.Compiler.LambdaCompiler.AnalyzeLambda( Parameters) in 
    System.Linq.Expressions.Compiler.LambdaCompiler.Compile( Parameters) in 
    System.Linq.Expressions.LambdaExpression.Compile( Parameters) in 
    System.Linq.Expressions.LambdaExpression.Compile( Parameters) in 
    Microsoft.Practices.ObjectBuilder2.DynamicBuildPlanGenerationContext.GetBuildMethod( Parameters) in 
    Microsoft.Practices.ObjectBuilder2.DynamicMethodBuildPlanCreatorPolicy.CreatePlan( Parameters) in 
    Microsoft.Practices.ObjectBuilder2.BuildPlanStrategy.PreBuildUp( Parameters) in 
    Microsoft.Practices.ObjectBuilder2.StrategyChain.ExecuteBuildUp( Parameters) in 
    Microsoft.Practices.ObjectBuilder2.BuilderContext.NewBuildUp( Parameters) in 
    Microsoft.Practices.Unity.ObjectBuilder.NamedTypeDependencyResolverPolicy.Resolve( Parameters) in 
    object.lambda_method( Parameters) in 
    Microsoft.Practices.ObjectBuilder2.DynamicBuildPlanGenerationContext.( Parameters) in 
    Microsoft.Practices.ObjectBuilder2.DynamicMethodBuildPlan.BuildUp( Parameters) in 
    Microsoft.Practices.ObjectBuilder2.BuildPlanStrategy.PreBuildUp( Parameters) in 
    Microsoft.Practices.ObjectBuilder2.StrategyChain.ExecuteBuildUp( Parameters) in 
    Microsoft.Practices.Unity.UnityContainer.DoBuildUp( Parameters) in 
    Microsoft.Practices.Unity.UnityContainer.DoBuildUp( Parameters) in 
    Microsoft.Practices.Unity.UnityContainer.Resolve( Parameters) in 
    Microsoft.Practices.Unity.UnityContainerExtensions.Resolve<object>( Parameters) in 
    Prism.Unity.Navigation.UnityPageNavigationService.CreatePage( Parameters) in 
    Prism.Navigation.PageNavigationService.CreatePageFromSegment( Parameters) in 
    Prism.Navigation.PageNavigationService.ProcessNavigationForRootPage( Parameters) in 
    System.Runtime.CompilerServices.AsyncTaskMethodBuilder.Start<Prism.Navigation.PageNavigationService.<ProcessNavigationForRootPage>d__16>( Parameters) in 
    Prism.Navigation.PageNavigationService.ProcessNavigationForRootPage( Parameters) in 
    Prism.Navigation.PageNavigationService.ProcessNavigation( Parameters) in 
    System.Runtime.CompilerServices.AsyncTaskMethodBuilder.Start<Prism.Navigation.PageNavigationService.<ProcessNavigation>d__14>( Parameters) in 
    Prism.Navigation.PageNavigationService.ProcessNavigation( Parameters) in 
    Prism.Navigation.PageNavigationService.ProcessNavigationForAbsoulteUri( Parameters) in 
    Prism.Navigation.PageNavigationService.NavigateAsync( Parameters) in 
    Prism.Navigation.PageNavigationService.NavigateAsync( Parameters) in 
    

    20 of 20 samples I have done when I feel things stall, I found the runtime with following two stack frames on top:

    System.Runtime.CompilerServices.RuntimeHelpers.TryEnsureSufficientExecutionStack() in 
    System.Linq.Expressions.StackGuard.TryEnterOnCurrentStack() in 
    

    Are you aware of any changes with regards to expression trees in 15-2?

    Br, Kasper

    Tuesday, May 2, 2017 8:39 AM

All replies

  • User2593 posted

    Same problem with 15-2-preview-2

    Br, Kasper

    Friday, May 5, 2017 8:02 AM
  • User2593 posted

    I have the same issue with the new stable release of 15-2 :( Perhaps the factor is only 3-4 now. Am I really the only one?

    Wednesday, May 10, 2017 11:13 PM
  • User275102 posted

    We are also having huge issues with performance degredation since 15.2. Specifically, in one part of our app, a relative layout is populated with several child items, this took only 2-4 seconds yesterday. Today, after updating, it takes upwards to 60 seconds (without exaggeration). It took most of my day to troubleshoot, but we finally realized that the app worked fine on machines that hadn't updated to the new version of Xamarin yet.

    EDIT: how can one roll back to an older version of Xamarin anyway?

    Thursday, May 11, 2017 9:56 AM
  • User258 posted

    We're seeing the same

    Thursday, May 11, 2017 10:00 AM
  • User251799 posted

    Same here. I have a startup time of multiple minutes now. Prism application, loading a simple screen. However, I think a lot of time gets lost even before initial navigation takes place.

    Thursday, May 11, 2017 12:36 PM
  • User92861 posted

    Hey all, I'm still seeing this issue with the stable 15.2 release when using the Xamarin.Forms RelativeLayout and I've filed a bug report with Xamarin.Android so we can track this: https://bugzilla.xamarin.com/show_bug.cgi?id=56240

    Thursday, May 11, 2017 6:07 PM
  • User92861 posted

    @PhilippSumi @KasperOvergrdNielsen Would one of you be able to provide your project or a sample project that does not use a RelativeLayout and reproduces this issue? Thanks!

    Thursday, May 11, 2017 6:53 PM
  • User258 posted

    I'm seeing massive slowdown in a project that does not use RelativeLayout. In the vicinity 60-90 seconds on startup. It does use Prism. Project is client owned and cannot be distributed.

    Thursday, May 11, 2017 7:12 PM
  • User213860 posted

    Same, massive slow down on Xamarin.Forms app.

    Friday, May 12, 2017 3:08 AM
  • User2593 posted

    @JimmyGarrido I cannot forward you the project in question, as it is client owned.

    However I'm fairly certain it has to do with compilation of expression trees. If memory serves me right, RelativeLayout also uses expression trees.

    If you take a closer look at my first post, you will notice that the my "poor-man" profilling revealed that:

    System.Runtime.CompilerServices.RuntimeHelpers.TryEnsureSufficientExecutionStack() in 
    System.Linq.Expressions.StackGuard.TryEnterOnCurrentStack() in 
    ...
    

    Is the culprit. I briefly read the code on github, and it seems to be checking to see if evaluating the expression would deplete the stack of the current thread, and if so, do something completely daft like moving part of the evaluation to another thread to ensure there is enough stack space. Anyway, it is the compilation step that kills performance, more than the actual evaluation.

    I have another project for the same client that does not use Prism, and hence Unity, where the performance degradation during startup is less than 20%. Pretty bad in itself, but much better than 400%. Startup time has always been a sore point of Xamarin apps, even without Xamarin.Forms, and it is very visible and easy to measure.

    Expression trees are one of the coolest features of .net, please don't make us abandon them

    Friday, May 12, 2017 11:49 AM
  • User92861 posted

    @KasperOvergrdNielsen I saw that you commented on the report and added this information. Thank you for that! We are looking into this being a more general and non-Forms related issue and we will be updating the report during our investigation.

    Friday, May 12, 2017 3:12 PM
  • User139758 posted

    This makes everything completely unusable. We need a fix soon!

    Sunday, May 14, 2017 7:33 PM
  • User251799 posted

    @JimmyGarrido is there an ETA on a fix? This sounds as if the latest VS 2017 update basically breaks Android development for everybody.

    Sunday, May 14, 2017 9:43 PM
  • User97236 posted

    Hi - I updated yesterday. I use Prism 6.2 and Xamarin.Forms.2.3.2.127 - after a "vs for mac" install I got error in Android XamlCTask that it did not find xxxxx.dll.mdb. I tried uninstall. I even modified the XamlCTask-problem (that actually worked but it seems like a bad idea to modify this file). This was prior to updating everything.

    Then I upgraded to Prism 6.3 and to the new Xamarin.Forms. Everything worked and I was very pleased. iOS worked like a charm. Android worked but performance was terrible. As is "not usable". Like another user here wrote it loads a lot of stuff. But it just takes forever. I have 30 seconds plus startup time. And pressing a button is not very responsive. I have tried to revert to my old setup but without luck. I don't know what is causing the problem.

    How do I install a older version on Xamarin.Studio and which mono compiler works? Or du I use another channel or something? I'm very open to suggestons. I did not see this coming. It does not matter it it is Xamarin.Studio or Visual Studio. Performance is VERY bad. Need fix - now.

    Very bad performance is delaying our release...

    Please help - or fix - or even a workaround would be great.

    Monday, May 15, 2017 6:06 AM
  • User2593 posted

    @BoHansen You need to downgrade to Xamarin.Android 7.2. Unfortunately Xamarin went stable with 7.3 to early, so you cannot simply change channel. You need to manually download and downgrade from here: https://store.xamarin.com/account/my/subscription/downloads

    Monday, May 15, 2017 8:01 AM
  • User97236 posted

    @KasperOvergrdNielsen Thanks! Nice answer. I will try your suggestion - that will work. I'm sure of it. I'm a bit disappointed that 7.3 went stable with this critical bug. It's a mystery to me. In the past I've been holding back with package upgrades due to the fact at most of the time a single upgrade would mean an entire regression test of my apps. Something always seems to be working a little bit different. But yesterday it actually worked - out of the box. I was very pleased what I did actually manage to upgrade and everything still worked. But what feeling went away once I discovered that performance was ridiculous down on Android. Horribly slow. Not releasable in any way. iOS was and has always been working like a charm :)

    So question : do I downgrade Xamarin.Android + Xamarin.iOS to 7.2 ? Or JUST Xamarin.Andorid to 7.2. Is is releated to Xamarin.Android alone? So this has nothing to do with "Xamarin Studio" or "VisualStudio For Mac" ? Mono 5.0.0.100 ?

    Monday, May 15, 2017 9:04 AM
  • User97236 posted

    @KasperOvergrdNielsen it worked with the downgrade of Xamarin.Android 7.3 -> 7.2 only ... thank god. I have currently use this:

    MonoFramework-MDK-5.0.0.100.macos10.xamarin.universal xamarin.android-7.2.0-7 xamarin.ios-10.10.0.33 XamarinStudio-6.3.0.864

    That working fine and Android has regained it's performance in Android.

    Prism 6.3 Xamarin.Forms 2.3.4.231 Netwtonsoft.Json 10.0.2

    Regards

    Monday, May 15, 2017 12:58 PM
  • User2593 posted

    @BoHansen If you face an issue with hitting breakpoints in Xamarin Studio after downgrading to Xamarin.Android 7.2, then you can try setting the default Mono Runtime to 4.8.1 (in preferences). That worked for me and a co-worker of mine.

    Monday, May 15, 2017 3:55 PM
  • User127707 posted

    @KasperOvergrdNielsen How do you download a second runtime? My preferences only show one option. I can click Add but am unaware of how to download 4.8.1 (or where its saved in the file system) on its own without downgrading everything else.

    Monday, May 15, 2017 4:13 PM
  • User2593 posted

    ls -l /Library/Frameworks/Mono.framework/Versions should show you what you have installed.

    Monday, May 15, 2017 4:36 PM
  • User127707 posted

    Thank you. You are correct.

    Monday, May 15, 2017 4:38 PM
  • User226914 posted

    We can confirm the same 20X reduction in performance especially when there are complex UI layouts, thus rendering every all of our Android apps unusable.

    Wednesday, May 17, 2017 3:03 PM
  • User226914 posted

    What about with Visual Studio 2017 - is there a downgrade/revert path? Currently running 15.2 which includes Xamarin.Android 7.3.0.13 and it is a forward-only installer.

    Wednesday, May 17, 2017 4:04 PM
  • User57024 posted

    Hey guys! Same performance issues here on Android.

    How do I downgrade Xamarin.Android on Windows / VS2017(15.2)?

    I downloaded and installed the previous version (4.4 - April 6, 2017) on Xamarin Downloads page but on visual studio nothing changed. In VS > Help > About still says Xamarin.Android SDK 7.3.0.13 (448f54f)

    Wednesday, May 17, 2017 7:59 PM
  • User92861 posted

    @SBSDev @tonholis To downgrade VS2017 go to this page and sign in with your MSDN account or sign up for VS Dev Essentials in order to access the download for 15.0.

    Wednesday, May 17, 2017 11:48 PM
  • User57024 posted

    Thanks @JimmyGarrido ! I thought that would be possible to downgrade just Mono/Xamarin.Android...

    Wednesday, May 17, 2017 11:59 PM
  • User324100 posted

    Here https://bugzilla.xamarin.com/show_bug.cgi?id=56240#c52 you can find a workaround for the performance issue

    Friday, May 26, 2017 8:33 AM
  • User324100 posted

    A new Visual Studio 2017 update (including Xamarin 4.0.5.476) is available. I installed it and it fixes the performance problem. Note: the update has been released only for Visual Studio stable version. It is not yet available for Visual Studio Preview, as mentioned here https://bugzilla.xamarin.com/show_bug.cgi?id=56240#c57

    Wednesday, May 31, 2017 8:25 AM