Why is the mobile web slow?
codenameone.com
Why is the mobile web slow?
1–10 of 48 posts
Re: Why is the mobile web slow?
#2> 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 your performance will be predictable and fast. ARC on the other hand doesn't allow you to do that since ARC instantly deallocates an object you finished working with.
I don't understand this. All the strategies one might use to avoid allocations in performance-critical code under GC (pooling resources, or whatever) are also available under ARC.
The difference is that if the way I use memory causes performance issues without GC, it will be much more reliably reproducible than with GC.
Re: Why is the mobile web slow?
#3So I don't know much about anything, but I'm confused on this point. You say "This effectively means it always performs late binding and invoking a message is REALLY slow in Objective-C." But I can't find any evidence of Objective-C performing late binding or in documentation [1][2][3][4].
[1] - http://stackoverflow.com/questions/5943949/late-binding-vs-d... [2] - http://www.gnu.org/software/gnustep/resources/ObjCFun.html [3] - http://developer.apple.com/library/ios/#documentation/genera... [4] - http://stackoverflow.com/questions/9470824/dynamic-binding-l...
Re: Why is the mobile web slow?
#4> 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 cached and for every subsequent call the cache is used.
Then there's some real neat trickery that is performed in objc_msgSend() ... after the method to "call" has been found the code directly jumps into that method without creating a new stack frame. (All needed arguments have been passed to objc_msgSend() and are already on the stack.) objc_msgSend() in essence is a trampoline.
So when sending a message to an object multiple times you only pay for the cache lookup - which is pretty fast by itself and a cached call is faster than a C++ virtual method call.
Performance Numbers: http://www.mikeash.com/pyblog/performance-comparisons-of-com...
More about objc_msgSend(): http://www.mikeash.com/pyblog/friday-qa-2012-11-16-lets-buil...
Now I don't know enough about Java but I guess it isn't much more faster than that. So calling Obj-C slow may be a little too bold.
Re: Why is the mobile web slow?
#5So I don't know much about anything, but I'm confused on this point. You say "This effectively means it always performs late binding and invoking a message is REALLY slow in Objective-C." But I can't find any evidence of Objective-C performing late binding or in documentation [1][2][3][4]. [1] - http://stackoverflow.com/questions/5943949/late-binding-vs-d... [2] - http://www.gnu.org/software/gnustep/resources/ObjCFun…
The original article seemed to have a mistake there, it now says dynamic binding. This is indeed much slower than regular invocation as the first article you linked to states.
Re: Why is the mobile web slow?
#6The 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).
Re: Why is the mobile web slow?
#7So I don't know much about anything, but I'm confused on this point. You say "This effectively means it always performs late binding and invoking a message is REALLY slow in Objective-C." But I can't find any evidence of Objective-C performing late binding or in documentation [1][2][3][4]. [1] - http://stackoverflow.com/questions/5943949/late-binding-vs-d... [2] - http://www.gnu.org/software/gnustep/resources/ObjCFun…
"Late binding" is a generalized term for associating a symbol with a value/code at run time, instead of compile/link time. (even if the term is not literally used in the obj-C docs)
Re: Why is the mobile web slow?
#8> 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…
Maybe this Objective-C optimization isn't implemented in iOS:
http://www.shannah.ca/blog/?p=226
Re: Why is the mobile web slow?
#9"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 completely within one function. You have to watch out for some gotchas like recursing into the same function, but overall it's a pretty painless and clear pattern for me. Multiple functions can all share the same static memory too.
Not that I'm religious about this design pattern, but it's something I try to do in performance-critical code.
Re: Why is the mobile web slow?
#10> 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…
Great, I gotta write (as if) in FORTRAN :-)