Hi Jolyon, To be honest, I do not have the time to develop app in java and c# just for benchmark purpose. I can only rely on google. :-) All I can say is the app I developed in Xamarin android is fast enough. To get a server call from Sydney, Australia to North Shore city Auckland, nz takes around 70ms is good enough for me. Without network call, working on local database on the samsung tab 2 tablet, the app's gui response is instant.
Regards Leigh On 30 July 2015 at 12:26, Jolyon Smith <[email protected]> wrote: > A DSP filter ? Again, focussing on execution efficiency of a highly > specialised algorithm, not "real world" application performance. And there > is no reason why you could not incorporate C code in an application where > appropriate, even if the bulk of your application does not require or > benefit from it. > > You keep coming up with numbers for what appear to me to be highly > artificial benchmarks. These are interesting from a compiler > implementation perspective, but not so relevant to real world applications > in relation to which you seem to be limited to "guess", "feel", "think". > > If the advantage were as clear cut as you seem to think then there would > be no benchmarks in which the exact opposite were established, yet there > are. All we can say then is that the benchmarks are not the whole story. > > After all (dragging this back peripherally to Delphi), FireMonkey is also > a native code solution, but a google of "FireMonkey performance" does not > yield a litany of praise for the advantage of native code (other than from > Embarcadero's marketing department). ;) > > > Unless you develop an application in both Xamarin AND in Java and then > compare them to each other, you really have no idea whether what you "feel" > is representative or not. The bottom line is that if your application > performance is acceptable, then great. That's all you really need be > concerned with. But this does not on it's own, nor even in conjunction > with unrelated benchmarks, lead to the incontrovertible conclusion that > it is the best it could possibly be. > > imho. ymmv. > > > On 30 July 2015 at 11:52, Leigh Wanstead <[email protected]> wrote: > >> 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 >> > > > _______________________________________________ > 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
