One of the mobile operating systems that we’re particularly excited to support is Android. Android’s capabilities are truly awesome and playing with the OS on the Samsung Galaxy S made me finally switch from my iPhone. If you’re unaware of the major leaps that Android has made and the technical superiority that it now shows over iOS, go check out a Galaxy S for yourself. The speed of the phone is amazing, the integration with Google services is fantastic and intuitive and it is hands-down the best phone I’ve ever used in my life. I’ve basically given up writing native apps for the iOS because of Apple’s attitude towards its developers and now that the Galaxy S has such a massive advantage over the iPhone, I see no reason to use one again (except to test Isogenic on). Now, rant aside…

Since Android 2.0 the built-in browser has supported HTML5 Web Workers.

In Isogenic, we use workers to offload intensive calculations to separate threads that would otherwise block the main thread and slow down the whole engine. One of the questions that needed answering is how fast can we run workers on an Android device? To benchmark this test, I’ve used a simple worker that literally does nothing else other than loop as fast as possible, counting frames and responding to requests from the main script to report its current FPS. This may not appear particularly useful but it is quite an important test because it tells us what the absolute fastest possible loop speed a worker can execute on a particular device. From there we can work out roughly how much work each worker can do in a single frame in the best case scenario, and help to calculate how much processing time each addition to the worker’s load is using up.

So in the worker we have two intervals set up. The first is an interval set to 1 millisecond and calls a function called “tick”. That function simply increments the variable “frames” by one. The second interval is called once every 1000 milliseconds (1 second) and stores the current value of “frames” into another variable called “frameCount” and then sets “frames” to zero.

On our main script, we set another interval that sends a request to the worker to report the current value of “frameCount” and the worker simply sends this back on receipt of the request message.

So How Does Android Stack Up?

Well, comparing the Android emulator running a virtual device with Android 2.1-update1 (the same OS that the Samsung Galaxy S currently runs – bring on the Froyo please!!), running one worker in the configuration detailed above, we get a pretty constant rate of 91 loops per second.

To compare this, on the Mac Mini we see a steady 247 loops per second (Chrome 6) and on my monster development machine running Win7 with a Core i7 we see a steady 250 loops per second (Chrome 6). Just an FYI, when testing on Chromium 8.0.561.0 (63349) the loops per seconds were exactly the same as Chrome 6 at 250. It seems that 250 loops per second is the fastest a worker can loop which also means that setting an interval of anything less than 4 milliseconds is pretty pointless.

So here is the data in table format:

So there you are! Even under the intense pressure of 16 workers all looping as fast as possible, the emulated Android device still manages to keep the speed of all workers above 86 loops per second. Now this may not seem very fast, but I will post new stats once the workers have been given something useful to do and I will also try to find the time to add the stats from a real device running Android 2.1-update1 (Samsung Galaxy S).

In other exciting news, we should have a video showing the Isogenic Engine running on our Samsung Galaxy S with a decent map size and touch-capable game controls pretty soon. If you’re an iPhone fan, you’ll have to wait a bit longer as Apple has not yet provided support for web workers in their iOS Safari.