[DUG] EMBARCADERO MY GRIPE

Thu Jul 30 11:52:11 NZST 2015

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://listserver.123.net.nz/pipermail/delphi/attachments/20150730/afbb856f/attachment-0001.html 