Hi Jolyon, Android ART is not end of the story. Compare to native c code, android art is slower.
Here is the benchmark http://www.learnopengles.com/a-performance-comparison-between-java-and-c-on-the-nexus-5/ It is still around double slower than native c code for android art. You mentioned about bridge issue, I guess it is not a big deal. It is just like network call. Network call is expensive. Any api call to network just increase a little amount of overhead and can be ignored :-) But I am surprised that xamarin async call is half seconds faster than java android in the benchmark I mentioned. :-) I guess the extra time overhead to update title text/ set font size is ignored compared to do the real work. I do not feel slower in my application using xamarin android related to extra overhead api call. I think it is faster than builtin java code in android framework. Regards Leigh On 30 July 2015 at 11:36, Jolyon Smith <[email protected]> wrote: > Real world performance of code is more complicated than whether it is > compiled native or not, especially when you are talking about a virtual > machine running within or on top of a foreign environment. Xamarin.Android > code may well be native code, but how efficient that code is comes down to > the original compiler and then also the JIT compiler. > > In addition, most Android applications will spend a lot of time invoking > services of the Android platform.itself, so the performance of the code > calling those services may have only a very slight bearing on the overall > performance of the application. Far more significant is the efficiency of > calls made between the application code and the platform services. For any > non-platform native approach (Xamarin, FireMonkey) there is necessarily a > "bridge" between the application code and the platform, so any performance > advantage of the native code on one side that bridge has to offset the > overhead of that bridge before it can offer any real advantage. > > And with ART, the platform native application code is now also native code > so any advantage there is now - theoretically - entirely lost, leaving only > the overhead of the runtime/platform bridge. > > Xamarin's benchmark tests execution efficiency of their generated code in > isolation. This is a meaningless benchmark since it entirely ignores the > real world impact of the overhead necessarily incurred by having to > constantly bridge from their execution environment to the platform services > on the device. Maybe Xamarin is faster there too, but if so why not > publish some benchmarks demonstrating that to be the case, rather than > benchmarks which have no relevance ? Again: Consider the source. > > Similarly mobile apps tend to spend a lot of time making network calls. > As you yourself observed, that can make a big difference in perceived > performance which has nothing what-so-ever to do with the execution > efficiency of the code *making* the network call. > > More importantly, all software has bugs - the more software you involve in > a solution, the greater the chance of encountering a bug that will > adversely affect your application and the harder it could be to identify > which component is responsible and obtain a resolution from whichever > vendor is responsible for that particular component in your stack. e.g. > such as the codegen error in .net framework 4.6 which can introduce bugs > even in existing applications. > > Consider the stacks: > > Xamarin: Xamarin / Mono compiler > Xamarin + Mono frameworks > Mono > runtime > Android > Delphi: Delphi compiler > FireMonkey framework > FireMonkey RTL > > Android > Elements: Elements compiler > Android > > > > > On 30 July 2015 at 11:11, Leigh Wanstead <[email protected]> wrote: > >> Hi Jolyon, >> >> The fastest code on android is native code which is compiled by c code. >> Xamarin Android is based on runtime library which I guess is compiled in C >> too. Microsoft's net framework is compile .net code into native code before >> run the byte code on the real device. >> >> Regards >> Leigh >> >> On 30 July 2015 at 11:07, Leigh Wanstead <[email protected]> >> wrote: >> >>> Hi Jolyon, >>> >>> If network round trip time has little or nothing to do with framework, >>> how you explain that url get different time from different framework? I >>> will assume that they will get similar time spent to get data on all >>> framework. >>> >>> Dalvik platform is slow which is agree by google. Dalvik is slower than >>> Sun's jdk on mobile platform I read somewhere on internet. The >>> consideration for dalvik is not speed, but app size. >>> >>> Regards >>> Leigh >>> >>> On 30 July 2015 at 09:06, Jolyon Smith <[email protected]> wrote: >>> >>>> But Leigh, network round trip times have little or nothing to do with >>>> Mono / Dalvik / ART. >>>> >>>> I shall leave the last word on Xamarin to someone else... >>>> http://www.whitneyland.com/2015/07/xamarin-review-2015.html >>>> >>>> I would also recommend reading the earlier post from the same author. >>>> >>>> Worth noting in these round-ups is the point about the lack of >>>> community assistance when it comes to finding Xamarin solutions to common >>>> platform issues (as opposed to the bugs and issues in Xamarin itself). As >>>> mentioned before, RemObjects Elements avoids this problem due to the fact >>>> that the solutions for Java / Objective-C from the "native" communities for >>>> those platforms, can be applied *directly* in Elements projects in a >>>> way that is not often possible with Xamarin. >>>> >>>> On 29 July 2015 at 15:57, Leigh Wanstead <[email protected]> >>>> wrote: >>>> >>>>> Hi Jolyon, >>>>> >>>>> It seems that we are going through the benchmark way :-) >>>>> >>>>> I tried to run the app in the url you mentioned and it crashed. >>>>> >>>>> How about you look at this url? >>>>> http://magenic.com/Blog/Post/4/Mobile-Development-Platform-Performance >>>>> >>>>> My work is getting data from server which is similar to test 3. >>>>> java version shows 2.369s and xamarin version shows 1.738s in that >>>>> url. That is around half seconds difference. >>>>> >>>>> I sometimes got around less than 70ms round trip time in my own test >>>>> to get data from server in sydney, Australian in north shore, Auckland, nz >>>>> if the server is not busy. That is amazing fast using Xamarin android. >>>>> >>>>> Most customers are in Australia. I guess that they might get around >>>>> 50ms round trip time. >>>>> >>>>> Regards >>>>> Leigh >>>>> >>>>> >>>>> On 29 July 2015 at 14:42, Jolyon Smith <[email protected]> wrote: >>>>> >>>>>> ... and if only I had a million dollars I would be rich. >>>>>> >>>>>> >>>>>> As for Xamarin performance, consider the source. By which I don't >>>>>> mean the code, I mean who is making what claims. >>>>>> >>>>>> >>>>>> http://stackoverflow.com/questions/17134522/does-anyone-have-benchmarks-code-results-comparing-performance-of-android-ap >>>>>> >>>>>> Any advantage is only seen in an Intel Android VM. On ARM (by far >>>>>> the most prevalent in terms of actual Android hardware), Dalvik beat >>>>>> Xamarin almost every time, until Xamarin.Android 4.7.11. >>>>>> >>>>>> What is odd about this is that these results are from 2013, over a >>>>>> year after Xamarin posted their claims about *astonishingly* >>>>>> superior performance vs Dalvik. It is interesting that Xamarin do not >>>>>> disclose what environment their benchmarks were run in. Also interesting >>>>>> that they do not compare themselves to ART which is the more relevant >>>>>> comparison going forward. >>>>>> >>>>>> In any event, I don't think there is any chance that Google will drop >>>>>> ART any time soon (they already dropped Dalvik) in favour of a Mono based >>>>>> implementation of Android. ;) >>>>>> >>>>>> >>>>>> >>>>>> On 29 July 2015 at 13:51, Leigh Wanstead <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Hi Jolyon, >>>>>>> >>>>>>> I mentioned to you before in the thread. If google choose to use >>>>>>> mono framework in android, xamarin apk size can reach several kb too. >>>>>>> The >>>>>>> reason for me to use Xamarin is the app developed by Xamarin using mono >>>>>>> framework is faster than dalvik before ART time. The load time for the >>>>>>> app >>>>>>> is not my main concern. I care about the speed running the app for whole >>>>>>> lifecycle. Here is the url >>>>>>> https://blog.xamarin.com/android-in-c-sharp/ >>>>>>> >>>>>>> Regards >>>>>>> Leigh >>>>>>> >>>>>>> On 29 July 2015 at 13:40, Jolyon Smith <[email protected]> wrote: >>>>>>> >>>>>>>> What a fabulous attitude. It's thanks to that sort of thinking >>>>>>>> that we now "need" machines with quad core 2.5GHz processors and 8GB >>>>>>>> of RAM >>>>>>>> just to run frikkin MS Word. >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> NZ Borland Developers Group - Delphi mailing list >>>>>>>> Post: [email protected] >>>>>>>> Admin: http://delphi.org.nz/mailman/listinfo/delphi >>>>>>>> Unsubscribe: send an email to [email protected] >>>>>>>> with Subject: unsubscribe >>>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> NZ Borland Developers Group - Delphi mailing list >>>>>>> Post: [email protected] >>>>>>> Admin: http://delphi.org.nz/mailman/listinfo/delphi >>>>>>> Unsubscribe: send an email to [email protected] >>>>>>> with Subject: unsubscribe >>>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> NZ Borland Developers Group - Delphi mailing list >>>>>> Post: [email protected] >>>>>> Admin: http://delphi.org.nz/mailman/listinfo/delphi >>>>>> Unsubscribe: send an email to [email protected] >>>>>> with Subject: unsubscribe >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> NZ Borland Developers Group - Delphi mailing list >>>>> Post: [email protected] >>>>> Admin: http://delphi.org.nz/mailman/listinfo/delphi >>>>> Unsubscribe: send an email to [email protected] >>>>> with Subject: unsubscribe >>>>> >>>> >>>> >>>> _______________________________________________ >>>> NZ Borland Developers Group - Delphi mailing list >>>> Post: [email protected] >>>> Admin: http://delphi.org.nz/mailman/listinfo/delphi >>>> Unsubscribe: send an email to [email protected] >>>> with Subject: unsubscribe >>>> >>> >>> >> >> _______________________________________________ >> NZ Borland Developers Group - Delphi mailing list >> Post: [email protected] >> Admin: http://delphi.org.nz/mailman/listinfo/delphi >> Unsubscribe: send an email to [email protected] with >> Subject: unsubscribe >> > > > _______________________________________________ > NZ Borland Developers Group - Delphi mailing list > Post: [email protected] > Admin: http://delphi.org.nz/mailman/listinfo/delphi > Unsubscribe: send an email to [email protected] with > Subject: unsubscribe >
_______________________________________________ NZ Borland Developers Group - Delphi mailing list Post: [email protected] Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to [email protected] with Subject: unsubscribe
