It feels like the author just hijacked the topic to rant about Objective-C. No big insights into why web apps are slow other than: javascript is not the bottleneck, rendering the dom (which is a complicated process) is.
Why is the mobile web slow?
21–30 of 48 posts
Re: Why is the mobile web slow?
#22> Objective-C doesn't use methods like Java/C++/C#, it uses messages like Smalltalk. This effectively means it always performs late binding and invoking a message is REALLY slow in Objective-C. Well, "always" is a little wrong. The first time a message is passed and the bound method is called by the runtime is significantly slower (~4x slower than a virtual method call in C++). But then this message/method pair gets…
Java can inline many of virtual calls, making them essentially as fast as static methods (= much faster than C++ virtual methods).
Though, while Java can, it looks like Dalvik generally does not (though, most of the info available seems to be 2.3-era; possibly things have improves since). It looks like 2.3 Dalvik can inline getters and setters, but it's certainly no Hotspot.
Re: Why is the mobile web slow?
#23"They can also reallocate elements into the stack frame rather than heap when they detect specific allocation usage." I've always been interested in whether this is done in various managed languages. Since I never know the answer, one pattern I've taken to is to allocate memory in static const/final fields that I would normally put on the stack in C, instead of doing a heap allocation to a variable whose scope is com…
Good Java JIT environments (HotSpot etc) do this. It looks like Dalvik does not.
Re: Why is the mobile web slow?
#24> Don't allocate when you need fast performance. This is good practice regardless of whether you are using a GC since allocation/deallocation of memory are slow operations (in fact game programmers NEVER allocate during game level execution). > This isn't really hard, you just make sure that while you are performing an animation or within a game level you don't make any allocations. The GC is unlikely to kick in and…
Wouldn't cleanup in an ARC setup be more (or just as much) dependent on de-allocations (or actually reference loss) than allocations, while in a GC environment a freeup (albeit less predictable and of higher impact) is mostly triggered by deallocation? At least that's what I understood from the article.
Re: Why is the mobile web slow?
#25Earlier quoted context omitted.
Java can inline many of virtual calls, making them essentially as fast as static methods (= much faster than C++ virtual methods).
Though, while Java can, it looks like Dalvik generally does not (though, most of the info available seems to be 2.3-era; possibly things have improves since). It looks like 2.3 Dalvik can inline getters and setters, but it's certainly no Hotspot.
Dalvik is designed around criteria that are nearly diametrically opposed to those for Hotspot. Hotspot goes for maximum performance. Dalvik's JIT compiler is designed for maximum impact on performance with minimum computation. In other words, Dalvik's JIT is designed for battery powered devices.
Re: Why is the mobile web slow?
#26> Objective-C doesn't use methods like Java/C++/C#, it uses messages like Smalltalk. This effectively means it always performs late binding and invoking a message is REALLY slow in Objective-C. Well, "always" is a little wrong. The first time a message is passed and the bound method is called by the runtime is significantly slower (~4x slower than a virtual method call in C++). But then this message/method pair gets…
Another good discussion of objc_msgSend() is: http://www.friday.com/bbum/2009/12/18/objc_msgsend-part-1-th...
Ah yeah, that's the article(s) I wanted to link here but couldn't find anymore. A very good read!
Re: Why is the mobile web slow?
#27Earlier quoted context omitted.
Though, while Java can, it looks like Dalvik generally does not (though, most of the info available seems to be 2.3-era; possibly things have improves since). It looks like 2.3 Dalvik can inline getters and setters, but it's certainly no Hotspot.
Dalvik is designed around criteria that are nearly diametrically opposed to those for Hotspot. Hotspot goes for maximum performance. Dalvik's JIT compiler is designed for maximum impact on performance with minimum computation. In other words, Dalvik's JIT is designed for battery powered devices.
Oh, sure, I absolutely realise that a very aggressive JIT wouldn't be ideal for Dalvik. However, given that the article is talking about how wonderful JIT is, it perhaps concentrates a little too much on all the wonderful JIT things that Dalvik (the only mobile JIT of serious interest to most developers) does not do.
Re: Why is the mobile web slow?
#28Earlier quoted context omitted.
Dalvik is designed around criteria that are nearly diametrically opposed to those for Hotspot. Hotspot goes for maximum performance. Dalvik's JIT compiler is designed for maximum impact on performance with minimum computation. In other words, Dalvik's JIT is designed for battery powered devices.
Oh, sure, I absolutely realise that a very aggressive JIT wouldn't be ideal for Dalvik. However, given that the article is talking about how wonderful JIT is, it perhaps concentrates a little too much on all the wonderful JIT things that Dalvik (the only mobile JIT of serious interest to most developers) does not do.
Since the article was written by a Sun guy Dalvik is probably not the area of expertise there...
Re: Why is the mobile web slow?
#29The takeaway I got from this: DOM reflows are the major unsolvable source of perceived slowness. Cool. So, in an app where you avoid reflows, is mobile web fast? Why or why not? How avoidable are reflows? Can anyone point me to any articles that talk about this specifically, or benchmarks that make this concrete? (I vaguely recall benchmarks that covered reflow, but it's a vague memory).
Would doing a majority of the reflow work on a canvas element help with speed?
Re: Why is the mobile web slow?
#30> This isn't really hard, you just make sure that while you are performing an animation or within a game level you don't make any allocations. That seems like a big 'just', at least in a multi-threaded application...
Ah, but if you're going to talk about multi-threaded applications, we're going to have to start talking about things like thread-safe reference counts...