Hi Jolyon, You are right. Maybe that you can write an email to Xamarin about this.
Regards Leigh On 3 August 2015 at 11:51, Jolyon Smith <[email protected]> wrote: > If it's the first/only Android development tool you install (or if you > don't care about any existing tools) then I am sure it is straight > forward. But if an installer is going to change existing components of > some other product/component then it should tell you what changes are > required/involved. > > Also I should have mentioned that the installer failed to detect the > Android SDK initially (again, no such problem with Elements) so I had to > tell it where the SDK was installed, at which point the installer appeared > to be intending to install it's own copy of the SDK *AND* update the > existing one. The identified, existing SDK was listed in *addition* to > the proposed new installation. > > First impressions last, as they say. > > On 3 August 2015 at 11:23, Leigh Wanstead <[email protected]> > wrote: > >> Good morning Jolyon, >> >> That is strange. >> >> I recall around four or five years ago I installed xamarin android the >> experience was quite straight forward. It was easier than eclipse to do >> development. >> >> You need to run android sdk manager to get everything up to date of >> course. Xamarin android rely on google android sdk. >> >> Regards >> Leigh >> >> On 3 August 2015 at 10:58, Jolyon Smith <[email protected]> wrote: >> >>> Well I tried installing Xamarin in order to rebuild my simple app using >>> that, to do a precise like-for-like comparison both in terms of performance >>> and development experience. >>> >>> But Xamarin insisted that I didn't have the necessary components of the >>> Android SDK or JDK, despite pointing it at my current installations. The >>> installations that are supporting my current Android development perfectly >>> adequately. >>> >>> The Xamarin installer insisted that it was necessary to update these >>> installations but wouldn't tell me exactly what it was going to do to them >>> and since I didn't wish to risk breaking my current development stack I've >>> had to postpone this exercise until I can spare the time to stand up a >>> sandbox for the Xamarin environment. >>> >>> >>> By comparison with Elements, when you install that if you already have >>> these SDK's it simply uses them. If you don't, it directs you to download >>> and install them. Any impact on the environment is then no different than >>> the impact on a platform native Android development stack. i.e. you can >>> only target API levels and framework libraries etc that you have installed, >>> which you use the Android SDK Manager to manage. >>> >>> If Xamarin has specific requirements that it requires in this area then >>> it really should at least tell you what those are rather than just saying >>> "Not good enough, I'm going to change things" without saying how. >>> >>> Not a good first impression. >>> >>> >>> On 3 August 2015 at 09:57, Leigh Wanstead <[email protected]> >>> wrote: >>> >>>> 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 >>>> >>> >>> >>> _______________________________________________ >>> 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
