Let's talk performance

24567

Posts

  • Paul-GolfingScribePaul-GolfingScribe CAMember ✭✭

    Heya @DavidOrtinau @EZHart - Thanks for the focus on performance. I just opened a bug where one line of code (Google.MobileAds.MobileAds.Configure) on a default new solution causes a second delay in Entry control focus.

    https://bugzilla.xamarin.com/show_bug.cgi?id=55246

    I hope this can get prioritization as I cannot release a Google.MobileAds edition until it is fixed or I have a work-around.

    I am happy to provide more information as needed.

    Thanks, Paul

  • rmarinhormarinho PTMember, Insider, Beta Xamurai

    @TonyD how are you getting your metrics btw ?

  • EZHartEZHart USXamarin Team Xamurai

    @ChristianFalch Ahead-of-time (AOT) compilation will definitely reduce the startup time of your application, because your application won't be spending as much time on just-in-time (JIT) compilation. However, there are trade-offs; if you look at the size of the generated application, I'm guessing it's much larger with AOT enabled.

    That said, we'd be very interested to hear more feedback on everyone's experiences with AOT enabled.

    I saw that the term AOT was part of a lot of the lines in my output window

    If you're seeing a lot of AOT "not found" messages, that's likely related to https://bugzilla.xamarin.com/show_bug.cgi?id=42933

  • ChristianFalchChristianFalch NODeveloper Group Leader ✭✭✭

    @EZHart I noticed the increase in size, my app grew from ~19 to ~29 megs - caused by the inclusion of the JIT'ed code. This is in my opinion a lot less scary than having a startup time around 3-4 seconds. In addition it should be possible to reduce the code size a little bit by using a tool like ProGuard.

    I'd really like to test out the AOT feature on some of my production apps, but I'm a little bit scared to make my customers my test bed for experimental stuff. Any background on why this is still experimental?

  • BradChase.2654BradChase.2654 USMember ✭✭✭
    edited April 17

    @ChristianFalch AOT LLVM for us on production works really well! That said, it only does after you spend a week making sure the settings are correct and nothing is getting taken out that you use in reflection or the like. Also you will need to download proguard directly and use that as the one included with the android SDK is too old.

    OK so after all that our speeds improved greatly! We would never release without it. Which leads to the next problem...

    The last release of Xamarin.Android breaks AOT with or without LLVM. So you cannot AOT anymore. You will need to switch back to VS 2015 and the last stable Xamarin.Android release(not the current stable) if you want to test it.

  • DH_HA1DH_HA1 USMember ✭✭✭

    @ChristianFalch what is the size of your app on the device? When I did those options it ballooned to 150MB

  • ClintStLaurentClintStLaurent USUniversity ✭✭✭✭✭

    @DH_HA1 said:
    @ChristianFalch what is the size of your app on the device? When I did those options it ballooned to 150MB

    Holly Sheep-deep Batman! Are you seeing that in the Application Manager? I see 1/3rd of that in an app that does continuous GPS tracking and transmitting, runs a USB scanner, does messaging back to a dispatcher, connects to engine ODBII port and polls for data, bunches of other REST, a few custom renderers, calls, blah... blah... blah...

    What the heck does your app do, to be that big? That's a massive amount of code. Or does it have a huge amount of hi-res images in the resources?

  • DH_HA1DH_HA1 USMember ✭✭✭

    @ChristianFalch I see you are using Shared Runtime can you uncheck that and Fast Deployment and see what happens

  • ChristianFalchChristianFalch NODeveloper Group Leader ✭✭✭

    @ClintStLaurent I think you need to deploy the Release version without shared runtime and fast deployment to get the real size of your app when deployed to a device. When trying to use AOT/LLVM on a debug build I don't see any difference in the output nor in the startup speed for the app.

    @DH_HA1 I see that the size grows on the device after deployment, but I'm not really scared of numbers like 150 megs on the device - the important part for me is the size to download (.apk) and the startup time.

  • ChristianFalchChristianFalch NODeveloper Group Leader ✭✭✭
    edited April 17

    @DH_HA1 You're tagging the wrong user in your last comment ;-) I'm talking about building with AOT/LLVM in Release mode - that seems to be the only viable way to get AOT going.

  • NMackayNMackay GBInsider, University ✭✭✭✭✭
    edited April 17

    @ChristianFalch

    For whatever reason, with no major changes and the same ad-hoc provisioning in cycle9 out app has jumped 9MB in size (Link SDK libraries).....thankfully no one noticed :*

  • EZHartEZHart USXamarin Team Xamurai

    @BradChase.2654 - when you say that the last release of Xamarin Android breaks AOT, what are you referring to?

  • BradChase.2654BradChase.2654 USMember ✭✭✭
    edited April 17

    @EZHart Stable Release 15.1.

    EDIT: And the new Alphas...
    EDIT2: I spoke about it in the forum's release thread: https://forums.xamarin.com/discussion/92448/stable-channel-and-vs-2017-15-1-aka-cycle-10-feature-release/p1

  • DH_HA1DH_HA1 USMember ✭✭✭

    @ChristianFalch I discussed this with Jon Pryor using partial AOT

    https://github.com/jonpryor/Scratch.MyCamera/blob/jonp-partial-aot/Documentation/PartialAOT.md

    Only copy the assemblies you want to help in speeding up startup times.

    Here are my results:

    I used Monitor to view the Activity displayed message to get the accurate times

  • EZHartEZHart USXamarin Team Xamurai

    @BradChase.2654 - I just verified that the same problem can occur on VS 2015 with the latest stable. It seems that moving your project to a folder without any spaces in the path will avoid the issue.

    I haven't verified it on VS 2017, but I suspect it would work there, too.

  • BradChase.2654BradChase.2654 USMember ✭✭✭
    edited April 17

    @EZHart ahh thanks for looking into it. When you say no spaces, you mean the entire directory structure? Because I dont use any. That was the first thing I went looking for :).

    To be clearer I dont use any special characters at all. The only ones I do use are "."s.

    EDIT: I just noticed I have some "Web References" directories scattered about in different projects...

  • EZHartEZHart USXamarin Team Xamurai

    @BradChase.2654 Sorry, I wasn't clear about that. Yes - the entire directory structure, up to and including the project folders themselves.

    I fired up a new project in the default VS 2015 location ("\Visual Studio 2015\Projects"), and AOT failed with the invalid characters error. I moved that project to a folder without spaces in the path and it worked just fine.

    Again, that's with VS 2015 and the latest stable release; I haven't tried it against VS 2017.

  • EZHartEZHart USXamarin Team Xamurai

    @DH_HA1 - out of curiosity, what are your linker settings for the results on that chart?

  • DH_HA1DH_HA1 USMember ✭✭✭

    @EZHart Link all. I haven't done this test in about 3 months so I need to update it with the latest forms.
    I also recently enabled Proguard which might help

  • ClintStLaurentClintStLaurent USUniversity ✭✭✭✭✭
    edited April 17

    .

  • AbdullahNAAbdullahNA INMember ✭✭
    edited April 18

    @ChristianFalch what is the Android Store apk download size difference you see between, with and without AOT? Is that the "store apk download size" you mentioned grew from ~19 to ~29 megs? I am also concerned only startup time and the download size. I understand it is very much a normal behavior to have a bigger size in "application manager" for any apps, even the apps which are built with Java.

  • ChristianFalchChristianFalch NODeveloper Group Leader ✭✭✭

    @DH_HA1 Thanks for the numbers and the pointer to the discussion with Jon Pryor. Interesting!

    @AbdullahNA I'm not done measuring everything yet, but as you say my opinion download size and startup time are the most important factors for our users.

  • AbdullahNAAbdullahNA INMember ✭✭
    edited April 18

    @ChristianFalch Thanks! I initially did not pay much attention to AOT, however after reading your post I thought to give it a try. So when compiled my ~29mb all abi apk goes to ~152 megs, and other abi apks go from ~21-24mb to ~46-50mb.

    My current apks without AOT with the size of ~21-24mb, shows on store as <10 mb. I am little concerned if I publish the new apks with AOT, it increases the size by more than 10 mb.

  • ChristianFalchChristianFalch NODeveloper Group Leader ✭✭✭

    @AbdullahNA As stated previously, startup time is a more pressing concern than increasing the download size.

    @EZHart What about looking into a partial AOT to increase startup like @JonathanPryor wrote in the above link, automating the process as part of the build could be of great help.

    Another question that I haven't found the answer to is: Is the JIT'ed code cached in any way so that it can be reused? If so the startup time should be long the first time the app starts, and subsequent launches should be really speedy. Wouldn't that be a good compromise between startup time and deployment size?

  • ClintStLaurentClintStLaurent USUniversity ✭✭✭✭✭

    @ChristianFalch said:
    @ClintStLaurent I think you need to deploy the Release version without shared runtime and fast deployment to get the real size of your app when deployed to a device. When trying to use AOT/LLVM on a debug build I don't see any difference in the output nor in the startup speed for the app.

    Wholly carp.... You weren't kidding. I learned a lesson there. I keep looking for a decimal point and don't see one. Its 10x the size.

  • ChristianFalchChristianFalch NODeveloper Group Leader ✭✭✭

    @ClintStLaurent What's the size of the apk-file?

  • ClintStLaurentClintStLaurent USUniversity ✭✭✭✭✭

    @ChristianFalch said:
    @ClintStLaurent What's the size of the apk-file?

  • ChristianFalchChristianFalch NODeveloper Group Leader ✭✭✭

    @ClintStLaurent Big enough for sure... What's the size without AOT, both installed and apk, just for comparison?

  • ClintStLaurentClintStLaurent USUniversity ✭✭✭✭✭

    @ChristianFalch said:
    @ClintStLaurent Big enough for sure... What's the size without AOT, both installed and apk, just for comparison?

    Seemed like a good info-graphic to put together. At some point my boss will want the same numbers and I'd like to better understand these settings.

  • ChristianFalchChristianFalch NODeveloper Group Leader ✭✭✭

    Great work, @ClintStLaurent! As expected the size of the app when using the shared Mono Runtime will be a lot smaller than when building in release mode, but still a huge difference between the two release mode examples.

    What we could try to do is to create the same infographic for a blank, new app and for one of the samples from Xamarin - this would make it easier for people to compare with their own work.

    Looking forward to hear more about how JIT'ed code is cached on the device (if it is cached) at runtime - @JonathanPryor or @EZHart?

  • ClintStLaurentClintStLaurent USUniversity ✭✭✭✭✭

    @ChristianFalch said:
    What we could try to do is to create the same infographic for a blank, new app and for one of the samples from Xamarin - this would make it easier for people to compare with their own work.

    I'm happy to do that off company time. I can run that up tonight from home. Though it will be on VS2017 (latest v 15.1) since that is what I run at home.

  • MichaelRumplerMichaelRumpler ATMember ✭✭✭✭

    @EZHart

    There are now up to three renderers for some controls. How are component vendors supposed to specify the right renderer?
    In MR.Gestures I need a custom renderer for each and every control. For AppCompat I created separate controls (MR.Gestures.AppCompatButton) which use other renderers (MR.Gestures.Android.Renderers.AppCompatButtonRenderer which inherits from Xamarin.Forms.Platform.Android.AppCompat.ButtonRenderer). This is pretty awkward but with only the ExportRendererAttribute and without knowing if the end user uses AppCompat or not I cannot do anything better.

    Will this become even worse with the FastRenderers? Is there a better way how I can configure the correct renderer?
    It would be great if I could do

    Xamarin.Forms.Internals.Registrar.Registered.Register(typeof(MR.Gestures.Button), typeof(MR.Gestures.Android.Renderers.ButtonRenderer));
    

    in my initialization.

  • ClintStLaurentClintStLaurent USUniversity ✭✭✭✭✭
    edited April 18

    (MR.Gestures.Android.Renderers.AppCompatButtonRenderer which inherits from Xamarin.Forms.Platform.Android.AppCompat.ButtonRenderer).

    Oh boy... More long-arse file paths to fail. By the time this gets nested...
    F:\TFSworkspace\Clients\CoolCompanyName\2016\WhizBangApp\WhizBangApp.droid\Renderers\MR.Gestures.Android.Renderers.AppCompatButtonRenderer

    I'm not getting on Michael... I'm pointing out how what he needs to do because of the multiple renderers will eventually result in issues for developers.

    Several packages have issues with long file names for similar reasons and that issue could use some attention.

  • Garyb99Garyb99 USMember ✭✭
    edited April 18

    @DavidOrtinau Seems like a good update so far.

    How about this code though:

    if (Device.OS == TargetPlatform.Android)
    {
    //Do something here.
    }

    It says TargetPlatform and Device.OS is deprecated. What's the replacement?

  • ClintStLaurentClintStLaurent USUniversity ✭✭✭✭✭
    edited April 19

    http://motzcod.es/post/159684940967/important-onplatform-changes-xamarin-forms

    However I am finding that the new OnPlatform breaks all my XAML resources in App.xaml, and the C# receives a null when trying to get the KeyValuePair values for each platform.

    Old syntax works.
    New syntax breaks.
    https://forums.xamarin.com/discussion/comment/265673#Comment_265673

  • Garyb99Garyb99 USMember ✭✭

    @ClintStLaurent said:
    http://motzcod.es/

    However I am finding that the new OnPlatform breaks all my XAML resources in App.xaml, and the C# receives a null when trying to get the KeyValuePair values for each platform.

    Old syntax works.
    New syntax breaks.
    https://forums.xamarin.com/discussion/comment/265673#Comment_265673

    Alright, thanks for this. I think I'll stick with the old one for now.

  • DirkWilhelmDirkWilhelm USMember ✭✭✭

    Regarding the size of the .apk file:

    If we use AOT and select multiple architectures, will the sourcefiles be compiled for each selected architecture and included in the apk?

    If yes, then checking the option "Generate one package per selected ABI" should reduce the filesize, right?

  • ChristianFalchChristianFalch NODeveloper Group Leader ✭✭✭

    @DirkWilhelm Sounds like a good idea to test out. Thanks for the input!

  • EZHartEZHart USXamarin Team Xamurai

    @MichaelRumpler - The short answer is "change your AppCompat custom renderer to derive from the fast renderer".

    If I'm understanding your question correctly, you've already got two custom renderers. One is based on Xamarin.Forms.Platform.Android.ButtonRenderer and the other is based on Xamarin.Forms.Platform.Android.AppCompat.ButtonRenderer. If you don't change anything at all, these will continue to work as they always have.

    The "fast" button renderer is intended to replace the AppCompat button renderer. If you want to take advantage of the "fast" button renderer, you would just change from

    MR.Gestures.Android.Renderers.AppCompatButtonRenderer : Xamarin.Forms.Platform.Android.AppCompat.ButtonRenderer
    

    to

    MR.Gestures.Android.Renderers.AppCompatButtonRenderer : Xamarin.Forms.Platform.Android.FastRenderers.ButtonRenderer
    

    This may require a few other modifications to your custom renderer, but that's the gist of it.

    With that change, your current ExportRendererAttribute usage should remain the same.

    Does that make sense? Or have I misunderstood the question?

    As for the renderer registration akwardness (and I agree, for the AppCompat situation on Android it is awkward), that sounds like a good candidate for a proposal in the Evolution Forum.

Sign In or Register to comment.