Ok thanks for explanations !
I wasn't thinking there is a factor of 12 between computer and mobile
devices oO
On Tuesday, July 26, 2016 at 5:19:24 PM UTC+2, shannah wrote:
>
>
> On Tue, Jul 26, 2016 at 7:40 AM, Jérémy MARQUER <jrmy...@gmail.com
> <javascript:>> wrote:
>
>> Hi all,
>>
>> Steve, I think what you have mentionned here is very interesting... We
>> don't have so much informations (dev guide, forum...) about performances on
>> iOS related to Java Objects. It's very abstract since we don't know exactly
>> how java object are converted in objective C.
>>
> It is converted to C, not objective C. You're right. There isn't that
> much info in the dev guide. Performance will vary on what you are doing.
> Some things are highly optimized as they fall in critical code paths that
> we needed to pay close attention to. Some use-cases may not be as
> optimized. Generally, if I see a case that produces poor performance, I'll
> look at the C code that is generated and see if there is anything I can do
> to improve it. In some cases the solution is to just implement a couple of
> critical methods directly in C. Other times I decide to tweak how ParparVM
> actually generates C for a particular code pattern. Xcode has fairly
> decent profiling tools to make this sort of analysis possible.
>
> But.... Warning, this type of optimization is not for the faint of heart.
> Performance should already be quite good for most apps. I would look here
> *only* as a last resort after you've gone through your own code and found
> any bottlenecks. Java IDEs provide lots of great profiling tools that will
> allow you to identify bottlenecks well before you hit the device.
>
>
>>
>> I know in Java difference between StringBuffer/Builder, Hashtable/HashMap
>> etc but it's pretty difficult to apply this to ios platform. You said that
>> replacing some java object "increase performance by a factor of 3.5" on iOS
>> : how did you the benchmark ? I think it could be interesting to have more
>> documentation about performance linked to the platform.
>>
>
> Those benchmarks were done a few years ago when we were using the XMLVM
> back-end. XMLVM was *very* slow with object locking/synchronization.
> Knowing this, I was able to get dramatic performance increases by replacing
> Hashtable with Hashmap (etc). ParparVM has much better synchronization
> performance so such gains don't exist at the same level. You can still get
> marginal gains by choosing classes and structures that aren't thread-safe,
> but not like on XMLVM.
>
> For example :
>> JSONObject object = new JSONObject(json);
>> JSONArray arrayOfObjects = index.getJSONArray("myObjects");
>> With an array of about 3700 object --> This block takes 300 ms to execute
>> in the simulator instead of 5 SECONDS on ios ...
>
>
> That's not really a fair comparison. The desktop has so much more
> processing power than a hand-held device. a factor of 12 is actually quite
> a reasonable difference in processing time. A better comparison would be
> to parse these on the same device using different mechanisms (e.g. with
> standard C, or with another VM like RoboVM, Avian, XMLVM, or Zero).
>
> Steve
>
--
You received this message because you are subscribed to the Google Groups
"CodenameOne Discussions" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to codenameone-discussions+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/codenameone-discussions.
To view this discussion on the web visit
https://groups.google.com/d/msgid/codenameone-discussions/67ecd8a5-b070-4514-9d3c-a8799050986b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
