[DUG] EMBARCADERO MY GRIPE

Thu Jul 30 12:51:00 NZST 2015

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