6 ms·

How Google Chrome for Mac appears to launch so fast

103 points by johnw 17y ago

Oompa 17y ago
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.
- enomar 17y ago
  "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."
tumult 17y ago
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.
- jodrellblank 17y ago
  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?
  - tumult 17y ago
    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.
    - DrJokepu 17y ago
      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.
- pygy 17y ago
  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.
  - tumult 17y ago
    It does make sense in his case. It's still a hack, and he's still ignoring his own advice :)
jodrellblank 17y ago
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!".
- tumult 17y ago
  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.
  - jonknee 17y ago
    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.
    - deleted 17y ago
      [deleted]
    - jm4 17y ago
      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.
      - 17y ago
kingsley_20 17y ago
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.

103 points by johnw 17y ago

Oompa 17y ago

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.

enomar 17y ago
"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."

tumult 17y ago

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.

jodrellblank 17y ago
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?
- tumult 17y ago
  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.
  - DrJokepu 17y ago
    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.
pygy 17y ago
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.
- tumult 17y ago
  It does make sense in his case. It's still a hack, and he's still ignoring his own advice :)

jodrellblank 17y ago

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!".

tumult 17y ago
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.
- jonknee 17y ago
  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.
  - deleted 17y ago
    [deleted]
  - jm4 17y ago
    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.
    - 17y ago

kingsley_20 17y ago

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.