[DUG] EMBARCADERO MY GRIPE

[Leigh Wanstead]

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