Bayle Shanks's website: notes-computer-programming-programmingLanguageDesign-prosAndCons-objective-c

 Drew CrawfordWed 08th May 2013 at 12:11 am

@arthurkay

> Can you elaborate on why JS performance will always be worse than native languages on ARM devices?

There are people much more qualified to answer this question than I. But three things come immediately to mind:

1. GCed languages will never be as fast as non-GCed languages. Apple believes (and they employ many of the LLVM guys, who would know) that GC is an unacceptable performance hit with ObjC? on ARM, let alone with a more dynamic language like JS.

In many ways MonoTouch? has decided to take up the garbage collection torch. What they have demonstrated so far is 1) that the problem requires a multi-year effort writing a brand-new garbage collector, and 2) the performance is not particularly great. Compare, for example, the FPS while dragging shapes around in TouchDraw? (mono) with the same task in Omnigraffle (ARC). One is about 20fps and about 100ms behind user input, the other is smooth as butter.

2. JS uses hashmaps for the object model, and hashmaps are a lot slower than e.g. structs.

3. JS has much more dynamism. Dynamic typing, dynamic dispatch, closures, reflection, object runtime alteration… *In theory* languages like ObjC? support some of these, but in practice the type system affords the compiler much more information about how to optimize the dynamism away. For example, ObjC? supports dynamic dispatch, but it also supports static dispatch (via C) and in practice the compiler infers static dispatch anyway for ARC purposes. Or: blocks look a lot like closures, but if you read the spec it becomes apparent that it’s really a convenient subset of a closure that can be reasonably optimized by a compiler.

(note a reply to Crawford: http://danbricklin.com/log/2013_06_19.htm#jsspeed which says that yes, but in JS in browers, the browser handles a lot of functionality for you, e.g. text editing, that would take a lot of code otherwise)