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 <[email protected] > <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 [email protected]. 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.
