[DUG] EMBARCADERO MY GRIPE

Jolyon Smith jsmith at deltics.co.nz
Mon Aug 3 11:51:32 NZST 2015 

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

More information about the Delphi mailing list