View Full Version : Performance degredation from 0.91 to 0.92

2 Aug 2010, 1:40 PM
During the last couple of builds, we began to see some performance issues in the code and wanted to post on what we have determined to be the issue and keep everyone informed on our progress. We are going to leave this up as a sticky for those interested.

Scrolling performance significantly changed between 0.9.1 and 0.9.2 (although we didn't change much in the Scroller class itself). The issue turned out to be the addition of documentation, which significantly increased the file size. This increased the compilation time of first time code execution, and thus the performance of the scroller. After switching out ext-touch-debug with ext-touch in the examples, everything started performing like before.

The reason Froyo didn't really suffer from this, is that they are using V8 engine, which compiles much faster, and thus the performance hit isn't that noticeable. The same applies to newer generation iPhones, which have better hardware specs and compiles faster.

We are currently investigating if the compilation time is related to the file size of the individual javascript file that the code exists in, or the total size of all the javascript on the page. If its the first, then we might have to split the framework into several files. If its the latter, then the only way to test actual performance is to use compressed and obfuscated javascript.

For now we have updated all examples to use ext-touch instead of ext-touch-debug, and we will keep you guys posted on further discoveries and developments regarding these issues. More details on the issue are below for the technically minded.


After lots of debugging, we determined that JavascriptCore (the Javascript engine used on iOS and Android 2.1) compiles functions right before they are executed for the first time (JIT). This is nothing new, and we were aware of this. What we didn't realize though, is that the compilation time is directly related to the Javascript file size. The following would happen:

User touches the screen for the first time
TouchEventManger fires touchstart event (compile)
Scroller executes onTouchStart (compile)

On older generation iPhones and Android 2.1, this compilation time could add up to several hundreds of milliseconds. During this time, the browser wouldn't fire any touch events, and the native behavior (scrolling the whole page) would take over. Then when you start moving, the same thing happened again.

User moves finger
TouchEventManager fires touchmove (compile)
Scroller listens for touchmove and executes onTouchMove (compile)
TouchEventManager fires scroll for first time (compile)
Scroller fires onScroll (compile)

During all this compiling, again the browser wouldn't fire any events and the native browser behavior would take over.

2 Aug 2010, 2:23 PM
Thanks for the update Tommy!

Has anyone tried using the minified version of sencha-touch on a Android 2.1 enabled device (Particularly the Motorola phone labeled "droid" in the US)? If so what were your results? I don't have a testing unit, but in the past I've tried some sencha apps on it and was unable to get them to perform (basically) at all.

2 Aug 2010, 3:38 PM

I have just tested all the demos on Android 2.1 on the Droid. With minified framework, and the performance improvements we have implemented over the past couple builds, the examples work much better then before and definitely good enough to be used. The framerate of CSS transitions is really the only thing less then desirable.

3 Aug 2010, 2:13 AM
Would it be possible to actually force JavaScript compilation for the whole page? Personally, I would not mind waiting for a few seconds just after a page is loaded in order to have smooth navigation later on.

3 Aug 2010, 2:32 AM
Well, very good, very good technology

23 Aug 2010, 8:32 PM
Jamie mentioned a new release this week. Still havent seen it. Will there be a release this week? Really waiting for the new nestedList.

15 Sep 2010, 12:46 PM
removing sticky bit, we're on .95 now