[DUG] EMBARCADERO MY GRIPE

Leigh Wanstead leigh.wanstead at gmail.com
Mon Aug 3 13:59:10 NZST 2015


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 <jsmith at deltics.co.nz> 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 <leigh.wanstead at gmail.com>
> 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 <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
>>>
>>
>>
>> _______________________________________________
>> 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/8695bff9/attachment-0001.html 


More information about the Delphi mailing list