Let's talk performance

12346

Posts

  • NamyslawSzymaniukNamyslawSzymaniuk USMember ✭✭✭
    edited July 14

    @JKay said:
    We have 115 nugets on our project :open_mouth:

  • BradChase.2654BradChase.2654 USMember ✭✭✭
    @JKay holy cow! That is a ton of packages. I wouldn't be surprised in the least if that is causing a large part of that. AOT can be a pain to setup if it's later in the project for sure. For us we had to use it so we had to go through the pain. It was worth it though. We do a ton of dynamic loading so it wasnt easy. You know what they say about humans, we tend to forget the pain. I will try to startup the way back machine and try to remember some things that made it easy for us if you still want to persue that path.

    Are all those packages necessary? I know stupid question but man just seems like alot. We built just about everything in house at the time because alot of the stuff we needed simply didn't exist which I guess worked out in the end but didn't seem so at the time.
  • JKayJKay USMember ✭✭✭

    I dont think half of them are needed. It just builds up when you install a nuget and it installs a load of dependencies and then you uninstall that dependency it leaves them all behind. I think i'll have to have a look at sorting them out

  • DH_HA1DH_HA1 USMember ✭✭✭

    @zahikramer does Costura.Fody work with xamarin?

  • zahikramerzahikramer ILMember ✭✭✭

    Yes @DH_HA1 , tested it and working!

  • PhilipGruebelePhilipGruebele USMember ✭✭

    @zahikramer Did this improve load time at all?

  • zahikramerzahikramer ILMember ✭✭✭

    @PhilipGruebele Not sure about that....

  • DH80DH80 USMember ✭✭
    edited July 17

    @zahikramer did it improve app responsiveness?

  • zahikramerzahikramer ILMember ✭✭✭

    @DH80 , @PhilipGruebele , It's working, but i didn't check it thoroughly.
    I didn't see much improvement , but more research need to be done.

  • DavidOrtinauDavidOrtinau USForum Administrator, Xamarin Team, Insider, University Xamurai

    @pauldbau I think you can accomplish what you want in your second case by making a custom layout class that allows you to control when the layout is invalidated and force it on your own.

    https://developer.xamarin.com/guides/xamarin-forms/user-interface/layouts/custom/

    For that matter, it's probably fundamentally what you've done to accomplish your first case.

    How is your timer solution working out for you? Can you share some results in terms of layout performance, responsiveness?

  • PhilippSumiPhilippSumi USMember ✭✭✭

    From glancing at Costura.Fody, this seems to just include external assemblies as resources, so that's probably not a real merge (a single assembly that contains all your code) that might help with performance issues. Those embedded assemblies still would have to be loaded, so there might even be a performance hit. I could be misinterpreting what's going on behind the scenes though, haven't used it.

  • zahikramerzahikramer ILMember ✭✭✭

    @PhilippSumi , this is why it needs more research.
    If anyone has numbers before and after....

  • DavidOrtinauDavidOrtinau USForum Administrator, Xamarin Team, Insider, University Xamurai

    @pauldbau @DavidDancy

    Yes, we have additional 3.0 refactoring planned to standardize the renderer APIs together and across target platforms, as well as further improving the ease of creating custom renderers/layouts.

    @DavidDancy I'm curious which utility classes you use most often?

  • RodyRody USMember ✭✭

    Do you need to have both AOT and LLVM turned on to see an improvement or just AOT?

  • NamyslawSzymaniukNamyslawSzymaniuk USMember ✭✭✭

    AOT is enought to see the difference

  • RodyRody USMember ✭✭

    @NamyslawSzymaniuk Thanks for the reply.

  • chetszotchetszot PLMember ✭✭

    Hello

    Regarding my experiences with Xamarin.Forms startup time performance.

    I am literally a 'boiled frog' with this framework. I have been developing my app for almost 2 years for now and I cannot afford to throw my work out (but I really wish I could switch painlessly to at least Xamarin.Android to gain startup performance) so I am forced to stay with it.

    Initially my app was starting over 22 seconds on dual-core phone and ~14 seconds on quad-core phone. My users thought that this stuff just hung and they killed and then uninstalled my app. I am pretty sure I lose many potential users because of terrible startup time.

    To gain performance I started adding views asyncronously in child threads in OnAppearing event. This really did the trick in my case nad reduced startup time by approx 10-20%:

    `Task.Run(() => InstantineCustomControl());

    private void InstantineCustomControl()
    {
    if (_customControl == null)
    {
    _customControl = new MyCustomXamlControl() { Margin = new Thickness(5, 5, 5, 5) };
    _customControl .SetBinding(MyCustomXamlControl.IsVisibleProperty, new Binding(nameof(MyViewModel.IsControlVisible)));

                Device.BeginInvokeOnMainThread(() =>
                {
                    LayoutRoot.Children.Add(_customControl );
    
                    Grid.SetRow(_customControl , 0);
                });
            }
        }`
    

    I hope this trick helps you a bit :)

    And then I have enabled AOT with LLVM, as suggested here.

    My startup times after async views initializing are as follows:

    Regular Release build:

    Samsung Galaxy S3 Mini: ~16s
    Samsung Galaxy Grand Prime: ~11s
    Samsung Galaxy A3 2016: ~8s
    Samsung Galaxy S6 Edge: ~7s

    AOT + LLVM Release build, each eABI in different APK:

    Samsung Galaxy S3 Mini: ~6s (MASSIVE improvement here)
    Samsung Galaxy Grand Prime: ~5s (MASSIVE improvement here)
    Samsung Galaxy A3 2016: ~8s (no change)
    Samsung Galaxy S6 Edge: ~7s (no change)

    Apps were uninstalled on all devices before updated with AOT + LLVM build. However, Galaxy A3 received update through Google Play beta app.

    Could please somebody explain me what happened here? Why and how it is possible that now my low-end devices outperforms higher-end ones?

    Thank you for any advice

  • LyndonHugheyLyndonHughey USUniversity ✭✭✭

    @NamyslawSzymaniuk said:

    @JKay said:
    We have 115 nugets on our project :open_mouth:

    I agree that this can't be good for performance, but it's almost necessary for an app that uses netstandard. For instance, I have an app that has:
    57 netstandard components
    12 "core functionality" components (BCL, .Net.Http, ModernHttp, etc)
    9 Xamarin.Android components.
    6 SqlLitePCLRaw components

    That puts the count to around 85 components just for the foundation of an app.

  • NamyslawSzymaniukNamyslawSzymaniuk USMember ✭✭✭

    @LyndonHughey said:

    @NamyslawSzymaniuk said:

    @JKay said:
    We have 115 nugets on our project :open_mouth:

    I agree that this can't be good for performance, but it's almost necessary for an app that uses netstandard. For instance, I have an app that has:
    57 netstandard components
    12 "core functionality" components (BCL, .Net.Http, ModernHttp, etc)
    9 Xamarin.Android components.
    6 SqlLitePCLRaw components

    That puts the count to around 85 components just for the foundation of an app.

    Don't use NetStandard 1.6/1.7.
    I'm using 1.4, and I don't need those "stupid" thousands System.* and Microsoft.* nugets.

  • JKayJKay USMember ✭✭✭

    @LyndonHughey This is pretty much my situation.

    I don't have a very good understanding of what NetStandard is, so I couldn't even tell you what version I am using.

    but the majority of my libs are Microsoft.* and System.* I have no idea if I need them all or what they are even doing.

    and then a handful of Xamarin libs. Then about 20 actual Third party components that I explicitly installed

  • LyndonHugheyLyndonHughey USUniversity ✭✭✭

    @NamyslawSzymaniuk I'm using NetStandard 1.4. My project.json file is attached in the spoiler section. This project started about 6 months ago, but there may be a more efficient way to add components now that the transition to NetStandard is further down the road. I had planned on revisiting this project's packages in the near future (once more components have moved over to NetStandard) but I would appreciate any insight on how to make this more efficient.

    {
    "supports": {},
    "dependencies": {
    "Acr.UserDialogs": "6.3.10",
    "Answers": "1.4.0",
    "Autofac": "4.6.0",
    "AutoMapper": "6.0.2",
    "Behaviors.Forms": "1.1.0",
    "CommonServiceLocator": "1.3.0",
    "Crashlytics": "1.4.0",
    "ExifLib.PCL": "1.0.1",
    "Fabric": "1.4.0",
    "Fody": "2.1.0",
    "FreshEssentials": "2.1.3",
    "Microsoft.Azure.Mobile.Client.SQLiteStore": "4.0.0",
    "Microsoft.Bcl": "1.1.10",
    "Microsoft.Bcl.Async": "1.0.168",
    "Microsoft.Bcl.Build": "1.0.21",
    "Microsoft.CSharp": "4.3.0",
    "Microsoft.NETCore.Platforms": "1.1.0",
    "Microsoft.NETCore.Portable.Compatibility": "1.0.2",
    "Microsoft.Win32.Primitives": "4.3.0",
    "NETStandard.Library": "1.6.1",
    "Newtonsoft.Json": "10.0.3",
    "Plugin.Fingerprint": "1.4.4",
    "Prism.Core": "6.3.0",
    "Prism.Forms": "6.3.0",
    "Prism.Unity.Forms": "6.3.0",
    "PropertyChanged.Fody": "2.1.3",
    "Refractored.MvvmHelpers": "1.3.0",
    "Rg.Plugins.Popup": "1.0.4",
    "sameerIOTApps.Plugin.SecureStorage": "1.2.2",
    "Splat": "1.6.2",
    "sqlite-net": "1.0.8",
    "SQLite.Net-PCL": "3.1.1",
    "SQLite.Net.Async-PCL": "3.1.1",
    "SQLite.Net.Core-PCL": "3.1.1",
    "SQLitePCL": "3.8.7.2",
    "Syncfusion.Xamarin.SfCalendar": "15.2.0.46",
    "Syncfusion.Xamarin.SfChart": "15.2.0.46",
    "Syncfusion.Xamarin.SfGauge": "15.2.0.46",
    "Syncfusion.Xamarin.SfListView": "15.2.0.46",
    "System.Collections.NonGeneric": "4.3.0",
    "System.Diagnostics.TraceSource": "4.3.0",
    "System.Net.Http": "4.3.2",
    "System.Net.NetworkInformation": "4.3.0",
    "System.Net.Requests": "4.3.0",
    "System.Net.Security": "4.3.1",
    "System.Net.WebHeaderCollection": "4.3.0",
    "System.Runtime.Serialization.Primitives": "4.3.0",
    "System.Security.SecureString": "4.3.0",
    "Toasts.Forms.Plugin": "3.2.0",
    "Toasts.Forms.Plugin-PCL": "3.1.4",
    "Xam.Plugin.Connectivity": "3.0.1",
    "Xam.Plugins.Settings": "3.0.1",
    "Xamarin.Build.Download": "0.4.6",
    "Xamarin.Forms": "2.3.5.253-pre5"
    },
    "frameworks": {
    "netstandard1.4": {
    "imports": "portable-win+net45+wp8+win81+wpa8"
    }
    }
    }

    @JKay You can check your project.json folder (located in the base of your PCL folder) to see what version you're using if you're using it.

  • DirkWilhelmDirkWilhelm USMember ✭✭✭

    @LyndonHughey in your project.json you have both Autofac and Prism.Unity.Forms. Are you really using two containers?

  • LyndonHugheyLyndonHughey USUniversity ✭✭✭

    @DirkWilhelm said:
    @LyndonHughey in your project.json you have both Autofac and Prism.Unity.Forms. Are you really using two containers?

    Good eyes. I looked at implementing Autofac, but decided against it. It is not referenced in code, but was still included as a package. It has been removed.

  • ChristianSvrdChristianSvrd SEMember ✭✭✭

    @DavidDancy said:
    @DavidOrtinau There are a few:

    • The entire WebViewRenderer ecosystem. When I needed to subclass the WebViewRenderer to make a secure version that checks the certificates of sites it visits, there were many little helper classes that were either internal or private. I ended up copying all of them. I also had to put the iOS renderer into a container so it would resize properly on device rotation.

    What kinda problem you had with the webview rotation? I think I have the same problem.

  • DavidDancyDavidDancy AUMember ✭✭✭✭

    @ChristianSvrd Basically when the device rotated, the WebView would not adjust its size to match the window's new width and height. There would be some blank space between the edge of the WebView and the edge of the application's window.

    The reason was that the WebViewRenderer on iOS was implemented as a UIWebView and some resize commands were missing. I implemented my version as a ViewRenderer<WebView, UIWebView> to match the other view renderers in the Forms suite, and the problem went away.

    It's still implemented as a UIWebView but this problem does not exist in the latest versions of Forms AFAIK (https://bugzilla.xamarin.com/show_bug.cgi?id=30047).

  • chetszotchetszot PLMember ✭✭

    Hello again

    Could please someone give me any tip why AOT + LLVM compilation does not reduce startup time on my Galaxy A3 2016 and Galaxy S6? Is it possible that AOT and LLVM does not reduce startup time?

    My build settings:

    • Release mode
    • Bundle assemblies into native code
    • One APK per selected ABI (I have even tried ARMv8 build and no improvement here as well)
    • Enable Multi-Dex
    • Linking SDK only
    • AOT + LLVM

    Before and after enabling AOT + LLVM, startup time of my app on Galaxy A3 2016 and on Galaxy S6 were ~8s and ~7s, so no improvements here in this case.

    What could I do to reduce the startup time? This is crucial factor for my app now :(

    Many thanks for any tips
    Best regards

  • zahikramerzahikramer ILMember ✭✭✭

    My solution for Android slow startup time WITHOUT AOT is Dual SplashScreen.
    You can virtually say that the startup time is cut by half.
    Check it out.

  • marcnegrimarcnegri CHMember ✭✭

    I have a lot of hope on improved performance. Particularly with listview component on Android (with Xamarin forms).
    Today, I'm using different custom Viewcells (with images, Stacklayout structures etc..) and unfortunately, I have very bad performance on Android. I'm looking for a miracle solution !

    It's for an important app. I'll try this new way, but I'm a little disappointed about doing new code in order to use same feature but faster :neutral:

    By the way, if someone has a solution for listview, give a sign :smile:

  • zahikramerzahikramer ILMember ✭✭✭

    Very interesting @ReinV !
    But you have to go through all the init code to enter 'Forms'. How is the performance?
    From 10sec delay how much can you cut to the first 'IntroPage' ?

  • ReinVReinV BEMember ✭✭
    edited August 23

    I did not benchmark it, but the 'perceived' speed gain was pretty good in our application

    We had some pretty gnarly setup,

    • getting information from KeyChain / Store
    • decrypting
    • Reading from files
    • Validating tokens
    • Loading profile information
    • Deciding if we should show a login page or not

    This all took some time, especially on Android, all this now happens in the background.

    If I have the time I'll try to benchmark it. We (my bosses / clients) were happy with the improvements

    If I could take a guess:

    3-4 seconds to the Intro Page
    2-3 seconds to the actual Page

  • BjornBBjornB USMember ✭✭✭

    @marcnegri said:
    I have a lot of hope on improved performance. Particularly with listview component on Android (with Xamarin forms).
    Today, I'm using different custom Viewcells (with images, Stacklayout structures etc..) and unfortunately, I have very bad performance on Android. I'm looking for a miracle solution !

    It's for an important app. I'll try this new way, but I'm a little disappointed about doing new code in order to use same feature but faster :neutral:

    By the way, if someone has a solution for listview, give a sign :smile:

    This is absolutely a bottleneck for android in xamarin forms. But it is actually not that hard to implement a native listview in android and use that in XF. And the performance is extremely fast, even if you were to be sentenced to death for bad UI code. I do most of my listviews native nowadays (only android).

  • BradChase.2654BradChase.2654 USMember ✭✭✭
    edited September 5

    @ClaudioPereira Just wanted to verify, we have been using those exact settings since they were in working order and have seen the same speeds for awhile now.

Sign In or Register to comment.