When Adobe SwitchBoard was announced the other week I was intrigued. It sounded like something I had been wishing for for a while: a better way to create user interfaces that leveraged the capabilities of the Creative Suite applications, something that the current scripting environment doesn’t do very well. I installed it and read the documentation and my entusiasm quickly faded. It’s the same lame impossible-to-use BridgeTalk technology as before with the same contradictory and strangely inter-application-incompatible API:s, but packaged differently. It’s true that you can create great user interfaces, but the scripting still sucks — and it turns out that it’s a resource hog.
Anyway, this wasn’t meant to be a review of the technology behind SwitchBoard, but a heads-up for anyone who, like me, installed it, abandoned it and thought no more of it: take a look at your CPU usage. For me, when I wasn’t actively using any other application, SwitchBoard was constantly among the top five processes sorted on CPU usage, using around 1%.
Get this: SwitchBoard is a deamon process that is running constantly, regardless of there being any other Adobe applications running let alone any AIR applications that would communicate with it, and it uses up 1% of the CPU without actually doing anything.
Unless SwitchBoard changes drastically in future versions I seriously recommend not installing it. It’s just not acceptable for background processes to quietly hog system resources without actually doing anything. 1% might not sound as much, but as a comparison it’s usually more than the [Mac OS X] WindowServer process uses.
I’m sadly not surprised by the lack of quality, it seems like this is the way of Adobe today, just look at the recently launched of Acrobat Reader 9 (have a look at Adobe 9 and Adobe Reader 9 is out), the user interface madness in the CS4 betas, last years debacle with the Apollo beta installers, etc. I really hope they reverse this trend, and soon. By the way, don’t get me started on Flex Builder.