[DUG] EMBARCADERO MY GRIPE

Leigh Wanstead leigh.wanstead at gmail.com
Mon Aug 3 11:23:51 NZST 2015 

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 <jsmith at deltics.co.nz> 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 <leigh.wanstead at gmail.com>
> 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 <leigh.wanstead at gmail.com>
>> 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 <jsmith at deltics.co.nz> 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 <leigh.wanstead at gmail.com>
>>>> 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 <jsmith at deltics.co.nz> 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 <leigh.wanstead at gmail.com>
>>>>>> 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 <leigh.wanstead at gmail.com>
>>>>>>> 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 <jsmith at deltics.co.nz>
>>>>>>>> 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 <leigh.wanstead at gmail.com
>>>>>>>>> > 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 <jsmith at deltics.co.nz>
>>>>>>>>>> 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 <
>>>>>>>>>>> leigh.wanstead at gmail.com> 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 <jsmith at deltics.co.nz>
>>>>>>>>>>>> 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: delphi at listserver.123.net.nz
>>>>>>>>>>>>> Admin: http://delphi.org.nz/mailman/listinfo/delphi
>>>>>>>>>>>>> Unsubscribe: send an email to
>>>>>>>>>>>>> delphi-request at listserver.123.net.nz with Subject: unsubscribe
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> NZ Borland Developers Group - Delphi mailing list
>>>>>>>>>>>> Post: delphi at listserver.123.net.nz
>>>>>>>>>>>> Admin: http://delphi.org.nz/mailman/listinfo/delphi
>>>>>>>>>>>> Unsubscribe: send an email to
>>>>>>>>>>>> delphi-request at listserver.123.net.nz with Subject: unsubscribe
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> NZ Borland Developers Group - Delphi mailing list
>>>>>>>>>>> Post: delphi at listserver.123.net.nz
>>>>>>>>>>> Admin: http://delphi.org.nz/mailman/listinfo/delphi
>>>>>>>>>>> Unsubscribe: send an email to
>>>>>>>>>>> delphi-request at listserver.123.net.nz with Subject: unsubscribe
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> NZ Borland Developers Group - Delphi mailing list
>>>>>>>>>> Post: delphi at listserver.123.net.nz
>>>>>>>>>> Admin: http://delphi.org.nz/mailman/listinfo/delphi
>>>>>>>>>> Unsubscribe: send an email to
>>>>>>>>>> delphi-request at listserver.123.net.nz with Subject: unsubscribe
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> NZ Borland Developers Group - Delphi mailing list
>>>>>>>>> Post: delphi at listserver.123.net.nz
>>>>>>>>> Admin: http://delphi.org.nz/mailman/listinfo/delphi
>>>>>>>>> Unsubscribe: send an email to delphi-request at listserver.123.net.nz
>>>>>>>>> with Subject: unsubscribe
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> NZ Borland Developers Group - Delphi mailing list
>>>>>>> Post: delphi at listserver.123.net.nz
>>>>>>> Admin: http://delphi.org.nz/mailman/listinfo/delphi
>>>>>>> Unsubscribe: send an email to delphi-request at listserver.123.net.nz
>>>>>>> with Subject: unsubscribe
>>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> NZ Borland Developers Group - Delphi mailing list
>>>>>> Post: delphi at listserver.123.net.nz
>>>>>> Admin: http://delphi.org.nz/mailman/listinfo/delphi
>>>>>> Unsubscribe: send an email to delphi-request at listserver.123.net.nz
>>>>>> with Subject: unsubscribe
>>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> NZ Borland Developers Group - Delphi mailing list
>>>>> Post: delphi at listserver.123.net.nz
>>>>> Admin: http://delphi.org.nz/mailman/listinfo/delphi
>>>>> Unsubscribe: send an email to delphi-request at listserver.123.net.nz
>>>>> with Subject: unsubscribe
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> NZ Borland Developers Group - Delphi mailing list
>>>> Post: delphi at listserver.123.net.nz
>>>> Admin: http://delphi.org.nz/mailman/listinfo/delphi
>>>> Unsubscribe: send an email to delphi-request at listserver.123.net.nz
>>>> with Subject: unsubscribe
>>>>
>>>
>>>
>>
>> _______________________________________________
>> NZ Borland Developers Group - Delphi mailing list
>> Post: delphi at listserver.123.net.nz
>> Admin: http://delphi.org.nz/mailman/listinfo/delphi
>> Unsubscribe: send an email to delphi-request at listserver.123.net.nz with
>> Subject: unsubscribe
>>
>
>
> _______________________________________________
> NZ Borland Developers Group - Delphi mailing list
> Post: delphi at listserver.123.net.nz
> Admin: http://delphi.org.nz/mailman/listinfo/delphi
> Unsubscribe: send an email to delphi-request at listserver.123.net.nz with
> Subject: unsubscribe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://listserver.123.net.nz/pipermail/delphi/attachments/20150803/e38e0cd2/attachment-0001.html

More information about the Delphi mailing list