How Google Chrome for Mac appears to launch so fast | Hacker News Reader

How Google Chrome for Mac appears to launch so fast

shipsomecode.com

103 pointsjohnw20 comments

So, while I’m certainly not recommending people start adding this code to their apps to provide the illusion of a faster launch

Do. I want the illusion of a faster launch almost as much as I want a faster launch.

What is it people rave about when they try SSDs? Is it the shock resistance? The power use? The noise? No. It's primarily "Wow, everything starts so much faster!".

It doesn't start any faster. It doesn't even appear to start any faster. The dock icon just doesn't bounce. People obsessed with application first-launch times but unwilling to run actual benchmarks measure "launch time" by whatever their monkey-eyes happen to be fixated to at moment. In this case, the dock icon they just clicked on. Oh man, it didn't even bounce once! It launched so fast!

Meanwhile, normal users click the Chrome icon and the window appears, and they start using it, instead of continuing to stare at the dock icon. Or even more likely, the app was already running.

It doesn't matter if it's real or not. If something is perceived to be faster, for all intensive purposes to the end user it is faster. You can provide a stop watch, but the user won't care--they will go with the appearances.

Users have been conditioned to judge startup time by the number of times an icon bounces in the dock. Chrome is only perceived as fast because the feedback is different from the other applications. It's all relative. Once enough developers start using this trick that perception is ruined and developers will have to resort to splash screens and progress bars again.

But the point is that the app is already loaded. It's just shifting the burden of loading from dock click to startup. The users probably won't notice that their system takes longer to start because it already takes so long compared to the loading of one application. (At least for most systems. I try to keep it as short as possible.)

If lots of developers do this the negative effects will be longer desktop loading times, the time from login to usable desktop, and more idle memory usage. With memory so cheap, I wouldn't be surprised if this becomes more common, though personally I think it isn't polite to the user.

Actually, no. The program still starts up when you click on it except it doesn't register itself as a foreground application until after it is loaded. The time to start the application is exactly the same, bootup time is unaffected, but the icon just doesn't bounce.

If you want that effect, you could turn off the dock bounce for applications. The problem I have with Google's approach is that it seems like the application didn't launch until it gets into the dock. Like, I double clicked it, but maybe the second click was off? It seems like the computer hangs before launching it when it actually did launch it and just didn't get the icon in the dock.

If the number of bounces makes you think apps are slow to start, you can disable dock bouncing. But you're totally right that it does make it feel like Chrome starts up faster.

exactly. I see this non-bouncing in a dock full of bouncy icons as a pretty big differentiator and it wouldn't surprise me if the very light-weight apps begin using the code by default.

um...i would imagine that if SSDs provided the illusion that applications loaded faster without actually improving performance, people wouldn't be shelling out $$$ for them.

You'd be surprised. CVT's (Continuously Variable Transmissions) in cars will smoothly adjust upwards in engine power, RPM, effective gear ratio, and audible pitch instead of pitching down and jerking at upshift like a traditional transmission. Supposedly, people had the illusion that CVT's weren't powerful because they didn't have audible "shifts", so CVT's were actually redesigned to provide the illusion of behaving more like traditional automatic transmissions.

I was using SSDs as an example that people care about startup speed to back up my assertion that improving startup speed is a good thing.

I wasn't suggesting SSD startup speed changes are illusory.

It's important to point out that doing this is a bad idea (as the author of the article notes.) The behavior specified by this plist value is meant for daemon processes. Google is using it because they run daemon processes for the window renderers in Chrome. The daemons need some of the Cocoa application stuff to render things like form inputs with native widgets, so they have to use some 'real' (NSApplication) Cocoa application stuff to get that that, which normally creates a dock icon for you (instead of just running a UNIX process.) This Info.plist value suppresses that behavior, along with the dock icon bounce and some other important stuff.

The author then goes on to ignore his own advice, and shows us demoing the trick in his own application.

It's important to point out that doing this is a bad idea

You've explained why it's done to get Cocoa components, but you haven't pointed out why it's a bad idea. It seems faster, which is good. Does it do any harm?

Its behavior for applications which use a GUI is unspecified by Apple (afaik) which means it could break at any time. Among other problems: Dock icon weirdness (no bouncing, status changes are strange) your app won't show up in the "Recent Applications" menu, your app won't be registered correctly in the process list, and likely some other stuff I can't name off the top of my head. Don't do it. You aren't an exception.

Indeed. "Smart people" abusing undocumented behaviour of Windows releases is usually the cause of compatability problems when a newer Windows version is released. You can read a few articles on Raymond Chen's The Old New Thing to get some understandong on how far Microsoft had to go to make sure that old programs doing stupid things kept working in new Windowses.

You don't abuse undocumented features of your environment as a developer. It's always a bad idea, it will always inevitably come back and bite you (or even worse, your users) a few years later.

It makes sense for the author to use it, since he wants to emulate the behaviour of the "Recent Applications", etc. Dock folders. A bounce is unwelcome in this case, and the other benefits of the normal application startup (like being registered in the "Recent Apps" list) are useless for him.

It does make sense in his case. It's still a hack, and he's still ignoring his own advice :)

A brilliant hack on Google's part. And it obviously works if the zero bounce is mentioned by others and used as an example of it's speed.

"What’s interesting is that the Chrome developers are actually doing this to workaround a completely unrelated issue involving the WebKit UI and it has even been filed as a bug. And to think we all thought they had done it deliberately to give the impression of a faster launch. Shame on us all."

Lookup UI feedback times. Bouncing the icon will actually make it appear more responsive. Same reason that for the few seconds that a web page takes to load you see some kind of spinning icon or page load indicator. Not having those reponse animations make the software look unrespinsive, not fast.

Reply on news.ycombinator.com