The footprint of the Air Ajax runtime
When I started to use Spaz, I naturally twitted about it and of one my friends tried it. He recognized that the application was better than Twitterific but did not adopt Spaz because of the OS resources consumed by the application. I know a bit the heart of Spaz as I developped a few of its features, I know that it does not waste resources and I concluded that perhaps the runtime could be the cause of this overhead.
This morning, I downloaded one of the simplest applications written in Air Ajax, the classic Hello World application. I simply executed the application adl -nodebug application.xml and used the Activity Monitor utility provided by Apple to measure the memory and CPU footprint. The question is simple: what is the overhead of an application that nearly does nothing and have nearly zero state ? Note that I use the -nodebug switch which optimizes the runtime, thanks to Ed Finkler that gave me the hint. It helps to reduce the CPU used by the application by a factor of 2. The first version of this entry did not take it in account.
Disclaimer: this test is very subjective and if someone else performs the same test, he will likely find a different result.
The answer is pretty big for me. My machine is a MacBook Pro 2ghz with 2 gigs of RAM (I can’t have more because it’s one of the early models). The application uses constantly around 2% of CPU and 20 megs
It is way too much for desktops. I wondered then how does it scale if I run 10 times the same application ? Perhaps that Air has a smart runtime that can collocate resources ?
According to my results, running 10 Hello World application consumes around 200 megs of RAM and around 20% of my CPU. Clearly I see a problem here, how can the end user really uses several Air applications at the same time without consuming too much OS resources ?
That reminds me the story of the Java virtual machine. Back in 2000, the early versions of the Java virtual machine were slow and gradually they improved the performance of their virtual machine. If I remember correctly the JDK 1.4 was the first release to provide decent CPU performances and then each major release had seen decent performance boosts. BTW: Sun’s VM also uses lot of memory but the CPU footprint is nearly zero. Reducing memory overhead is not achieved yet, I know they have plans to collocate if you execute several virtual machine though, I am not an expert.
I hope that Air will follow the same path and that Adobe will invest in the optimisation of the runtime. In my opinion it is a key factor to increase the adoption of the platform.

August 21st, 2008 at 9:14 pm
you know what’s weird though. I experienced a ton of issues with Spaz, and while they may be runtime related, I haven’t had a single resource issue/problem with twhirl (also AIR).
August 21st, 2008 at 9:34 pm
So, is the fault specific to AIR, or the use of WebKit?
August 21st, 2008 at 11:03 pm
@duff : hard to know as the memory footprint is global
@zack : with twhirl what is the idle CPU time used ?
August 22nd, 2008 at 4:46 am
Twirl is a hog too - 10% CPU, 60+ meg.
August 22nd, 2008 at 9:41 am
Yes, it does take 20 megs. I tried it out too. Its fault on the part of the air runtime definitely.
August 22nd, 2008 at 1:35 pm
JavaFX is pretty fat too. There isn’t a base CPU load, but 30 Mbs RAM on a hello world app is not uncommon.
August 22nd, 2008 at 2:50 pm
AIR itself isn’t slim, for sure. Instantiating a webkit instance makes it even bigger, though, but that’s not surprising: browser engines are not lightweight. What is particularly problematic is that there seem to be memory leaks within the webkit engine as used in AIR, and there is no way to profile memory usage. Apps like Spaz run into this problem because it’s constantly pulling in large amounts of new data, loading new images, and the like.
Also note that the CPU usage while idling is particularly a problem with OS X. On Windows, AIR seems to not have this problem.
I don’t think using 20MB or more is horrible, considering the technology. AIR is a full Flash runtime, and HTML apps add a webkit renderer on top of that. The memory and CPU usage is in line — or a bit lower — than most SSBs. Using traditional browser tech to build a desktop app is going to be a tradeoff in terms of memory and CPU usage, no doubt.
August 22nd, 2008 at 2:53 pm
@Finkler: I agree with you that 20megs is not the fundamental problem. For me the most problematic issue is the CPU consumed. Spaz itself consumes around 10% of my CPU even if it does not seem active (i.e just waiting the next refresh). About the leak, indeed the memory consumed seems to increase and Adobe does not provide the tools or the hooks (à la Java VM instrumentation) to properly know what happens.