So yeah, I went and ordered a TouchPad (a few actually, as they look like they’ll be useful as web/input devices). If you’re interested in picking one up for cheap, the epic SlickDeals thread (11K+ posts) has the latest stock info. (for general info, there’s another thread w/ some useful links, and the PreCentral TouchPad forums). It’s not for everyone, but $100 for a tablet w/ a 9.7″ XGA IPS screen, dual-core 1.2GHz Scorpion SoC (APQ8060 + Adreno 220), and 6300mAh battery that has a clean embedded Linux (and can easily chroot Ubuntu) is a steal.
Of course, if you’re not gonna be hacking on one, it’ll be a decent web browser or photoframe, and I have no doubt that the homebrew guys will keep plugging away for a while, but I’d treat it more as a disposable $100 purchase. (My thinking is the upcoming Amazon tablets will split the difference in pricing, but ultimately have much better longevity).
Now, back to the hardware for a bit. While there have been a rash of articles blaming the TouchPad’s performance on the hardware, I think that’s baloney. For those that aren’t regularly comparing ARM specs, all you need to know is that in terms of raw power, the Scorpion should hold it’s own – equivalent to current-gen Cortex-A9/GPU combo like Apple’s A5/SGX54x or Nvidia’s Tegra2 (maybe a little less memory bandwidth/IPC, but it has a faster clock). There’s an Anandtech article that does a good job summarizing.
The Anandtech article has a SunSpider comparison, which mirrors the launch benchmarks. The TouchPad is slow because the web layer is slow. Luna, webOS’s GUI, runs entirely on web layer. QED. This mirrors my cursory prelaunch SDK testing (NDA lifted 6/30).
I mostly gave up on webOS back in the summer of 2010, pre-HP acquisition, and although I retain a fondness for the idea of webOS, the execution has always caused ambivalence for me, primarily because of performance. I think Dion makes a bit of an understatement, when saying they should have spent more time profiling. More than any other feature or app (well, Maps), lag, OOM erros, and unresponsiveness was the primary issue that drove me away.
Although a lot of it comes down to doing (hard) low-level optimization work (or dumb easy stuff like turning off logging), I think at least some chunk is just due to running on old software. Last year at the Palm Developer Day, the excuse given about why webOS software was so out of date was due to recertification issues, but w/ webOS 3.x being a tablet-only fork, this obviously didn’t prove to be the ultimate reason.
Based on the 3.0.2 SDK Emulator, here’s a rundown of some of the stack:
Linux Kernel 2.6.26 was originally released Jul 13, 2008. In comparison, Android Honeycomb runs 2.6.36 (Oct 10, 2010). There is in fact an active project that’s done great work patching the kernel (better schedulers, governors, compcache), although I’m not sure if all the modules required to upgrade vs backport are available.
webOS reports using AppleWebKit/534.6. WebKit was tagged Safari-534.6 on Aug 27, 2010. This might not seem too bad when comparing w/ kernels, but to give some perspective, Chrome 7.0.517 was released with AppleWebKit/534.7 in Oct 21, 2010. I’m currently running Chrome 13.0.782.112, which uses AppleWebKit/535.1 (tagged on Aug 11, 2011). Safari 5.1 is using AppleWebKit/534.48.3 (tagged Jun 24, 2011). webOS has ACID compliance and other standards issues, and is lacking in many useful HTML5 features, which is somewhat ironic considering.
Probably more relevant to performance, however, is the V8 version. webOS’s node.js is compiled against V8 126.96.36.199-2 (released Nov 11, 2010). The current latest version, released last week, is 3.5.6. Especially for JS runtimes, improvements have been coming at a blistering pace. Running V8 Benchmark v6 on Chrome 13/Canary 15 (V8 188.8.131.52 and V8 3.5.6) on my desktop gave results in the 9400/9500 range. An old version of Chrome 7 (V8 184.108.40.206) scored… 5400 on the same test. (There BTW is your 2X performance.)
webOS 2.x+’s services are based on a node.js layer. That’s great. The version of node.js they are using is 0.2.3, which was released on Oct 02, 2010. The current version is 0.4.11 (stable) and 0.5.4 (unstable). node appears to run standalone, so that can probably be upgraded (and the JS tested) without too much trouble.
The much bigger challenge for people sticking with webOS is how to deal with all the custom-compiled/embedded bits. The biggest pieces (at least memory-wise) are the WebAppMgr, LunaSysMgr, and BrowserServer, but updating any the luna bits are completely dependent on the whim of HP.
If they don’t open source webOS, hopefully whoever’s left can push out as many of the low-level performance optimizations and maintain some sort of robust build/update system.
Sadly, the most likely scenario is that in a couple months we’ll just all be flashing an Android port.