Good morning Jolyon, I think that what you want is a benchmark to measure gui performance. In our case app written in java or c#
Here is the url http://www.phonearena.com/news/TouchWiz-speed-test-Does-Samsungs-interface-really-lag_id66407 I tried that tool gamebench and it does not test code written in xamarin android. Regards Leigh On 30 July 2015 at 12:51, Leigh Wanstead <[email protected]> wrote: > 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
