Pages

Saturday, April 10, 2010

Understanding flash on OS X

First of all
No, I am not dead. I just don't like to say stuff that no body want to read anyway so I kept my mouth (keyboard?) shut for a little while.

Second
Next review will be about whatever thing I'll buy next. It will probably be an iPad or the new rumoured MacBook Pros. I can't promise anything about this though.

Third, the reason of my post...
As many of you probably heard of already, iPhone OS 4 is coming soon and some of us, like me, already have the beta installed on their phones. Seriously, it is the best operating system I even seen on a phone since smartphone are in the market. There's a lot of stuff in it that apple didn't told you which can theoretically bring iPhone OS 4.0 up to par with any DESKTOP operating system out there. That's just how great it is.

Unfortunately, all that we seem to ear about it these days are bad stuff... which is kind-off strange actually. A big majority wanted multi-tasking. Now that they've got it, all that we can read is stuff like: "I don't really care about it, I would have preferred Flash that this." Yes, this article is dedicated to you, people that doesn't have any sense of mobile device logic.

Flash, a plague to avoid
The first reason why anybody would want to avoid Flash like a plague is about stability issue. Here's a nice one, while I've been writing this article, look what popped on my screen!


See, it managed to crash while doing nothing! That little thing made me wonder so I started to investigate on was could be the reason of this crash. After running a little software called Shark, a performance analyzer tool that come with Xcode, I discovered somethings that should have remained buried. What it does it that is detect cache miss (moments when requested data is not available in cache and need to be pulled from an other cache level) in the L2 processor cache and list them.

I have exported the report to a text file and I'm providing it for you to read on this link. It is very easy to understand. The numbers to the left are the numbers of call to a function, the gibberish in the middle is the memory emplacement of the function and the text at the right is the name of the library that provided the function. Now keep in mind that this report was requested during a normal writing session. I have music playing in iTunes and a couple of software is running. Notice anything strange here? First process in the list is the mack kernel (or the OS X subsystems if you prefer). It represent roughly 14.2% of the entire cache misses which is normal. The second one though... I expected it to be iTunes since it is doing realtime audio playback and require frequent access to the processor cache but... no...

In fact, Flash Player represent 51.7% of all the cache miss that happened during this session. Basically, it means that half of the calls that the required my computer to access the RAM during the 10 seconds of profiling happened because of the Adobe Flash library. This is a very good reason to consider it like a plague as it use as much CPU time as a virus! In fact, flash player used 1 minutes 32.24 seconds of CPU time in 4 hours of not using it. As a little comparison note, iTunes only caused 4.4% of the misses and used 9 minutes 23 seconds of CPU time in constant playback during the last 4 hours.

So, what does it mean? It means that Flash is not only very hungry CPU wise but also memory wise. It also show us that it is not optimized at all and keep on doing more and more request to the system memory.

Touch is the future
Based on what we can see today, people consider touch screen devices as the way of the future. It does have a little futuristic sense to it but believe me there's nothing impressive in them as they were in use since a good 10 to 20 years! Why am I talking about this? Because Flash is the complete opposite! Flash applications are generally built with a point-and-click interface so around 90% of them doesn't work at all on a touch based device like the iPhone. There's no way to access the various menus of the interface because you need to point at them and not click or tap on them. As a result even if you could run Flash on a touch based device like an iPhone, you would not be able of using it as it was not designed for this kind of usage.

Some websites like LinkedIn doesn't use Flash and still have some compatibility issues with a touch based interface because they try to limit their content to the size of the screen and use scrollbars to let you access the rest of it instead of thrusting the web browser and letting it do it's job.

Flash on the iPhone?
No way! Never! Not because it sucks performance wise and would drain your battery faster than light, but for the same reason I don't want an HP Slate. It was not designed to be used with touch in the first place.