I don't think ALT147 intends the "Show in Finder" item to be selected - click and hold to bring up the contextual menu. At this point, optionally, you could let go if you wanted to and the contextual menu will stay up. Clicking once will dismiss the contextual menu, and the icon becomes deselected. Clicking again at this point would be expected to launch the app, which it will, but not unless a certain amount of time has elapsed (ie an apparently unnecessary delay). And as ALT147 points out, continuing to click without allowing a pause between clicks could go on indefinitely and no further clicks on that area will be recognized. This affects all "Dock" contextual menus. Try control-clicking any folder in the "Dock". While the contextual menu is still up, pick any other "Dock" icon and start clicking away - the second item will not activate unless either the mouse is moved for some arbitrary distance (it seems to be 5-6 pixels in either direction) from the point where the second item was first clicked, or a pause occurs between clicks.

Such a delay can serve a purpose - in "Finder" column view for example, two quick clicks on a filename will open the item, but a click with a pause then a second click will allow the filename to be edited. A third click immediately after the second counts as a double click, but a delay between the second and third clicks will change the insertion point. Once the insertion point is positioned, the fourth click will either do nothing (if it comes after a delay), or it will highlight the word under the pointer in the filename (and a fifth click will either deselect the word and reset the insertion point, or select the whole filename).

In the case of the "Dock", I can't think of a reason behind the inclusion of the delay which makes the resulting slowdown all the more annoying.

It is interesting to note that ALT147 had said
This is interesting because I think the reason for the delay in the case of the Dock is to avoid the user launching an application unintentionally - when all they wanted to do was to get rid of the menu.

Here's what happens on my iBook G4 1.2 GHz (10.4.2):
- press and hold on Dock item until menu comes up
- release mouse button without moving mouse
- menu stays up
- start clicking rapidly
- menu goes away at first click, subsequent clicks are ignored until I stop clicking so rapidly (i.e. until there is a certain minimum delay)

This seems reasonable to me since it avoids the application getting launched in the case of a user whose response to the appearance of the menu is to rabidly (not a typo!) start clicking.
I.e. it follows the principle that UI actions should result only from user actions that are clearly intentional. If the user goes into a mode where it seems that he/she is clicking irrationally, the UI is correct to patiently wait for the user to come back to reason.

Ok, that doesn't sound unreasonable, as it guards against the "rabid" clicker. But think about it this way - if you do know what you want to do and your intention is in fact to dismiss the contextual menu and launch the app so you click twice (which is acceptable at low speed), the system has the gall to assume that you didn't really want to click twice.</anthropomorphism>

The user is forced to wait out this arbitrary delay before they can proceed, or they must use less efficient methods like moving the mouse slightly between clicks, or using the escape key to dismiss the contextual menu. If protection against unintentional app launching by irrational clickers is the reason behind the delay, then at some point the decision must have been made that the system was more likely to encounter an irrational user than an efficient one. The limiting factor determining how quickly a user can work then isn't how fast the system is capable of responding, or how fast the user can think (rationally), but rather the unconfigurable time delay built in to the GUI. I think it is those sorts of decisions or the presence of such behaviours in the GUI that contribute to the impression of slowness alluded to in the title of this thread.

Note that the enforced delay is a consequence of the user choosing a UI feature (the menu) and then deciding to back out of it (not wanting to use the menu). I still think it is reasonable to ignore subsequent clicks (after the first one that dismisses the menu) until a delay has occurred.

It is not all that uncommon for users to click multiple times when they only should click once. Many naive users double-click on everything - even links in web pages!

And most power users don't inadvertently trigger the Dock menu. This delay should therefor be a rather rare occurrence for them.

It's a matter of tradeoffs and greatest good for the greatest number.
If the delay were to be removed, some percent of naive users might experience a somewhat longer loss of time as an unwanted app launches (and then needs to be closed). If the percentage is high enough, this loss of time is likely to be far greater (when totaled over all OS X users) than the smaller and much less common delay incurred by power users backing out of a mistakenly triggered menu.

It might be a good idea to have this delay configurable. But each such configurable parameter requires testing and (at least internal) documentation. Such things increase the cost of development. There is no free lunch.

Not to nit pick, but the Dock is just an application that runs in OS X, so it being slow at something (or not) doesn't mean that the OS is slow.

Sorry, I tried to make clear what I meant, but I think you all worked it out anyway. I don't mean to select the 'Show in Finder' item, I mean to click 'out' of it, somewhere else on the app icon.

Exactly what I mean. Very well put: I wish I could have said it like that :D

All valid points, and I confess that they hadn't actually occurred to me. Now that you and others mention it, I see that there most likely is a logical reason behind it. But without actually having seriously thought about it, it's little things like this that, probably subconsciously, contribute to my sense of a sluggish UI.

Does anyone know if a similar delay exists for any UI elements on Windows, and, if it does, how long it is?

True, I suppose. But given that it is an important part of the OS X UI (or at least I would argue that it is), any subconscious suggestion of slowness on the part of the Dock rubs off on the rest of the OS :p

Yes, there are many. All those popup windows telling you that your network connection is now available... no longer available, etc. Those things are not just useless, they're annoying, distracting and any time spent moving the mouse to click the close box is a complete waste.

I find the ui on XP much slower than on any v of OS X I've run, including OS 10.0. Windows open slowly, Windows Explorer navigates slowly, moving through the Start menu is slow (1.7 Ghz, 40 G, 512 RAM -- no viruses or spyware). It was all very snappy at first, but has slowed steadily through the months. I don't find OS X slowing down like this.

I agree with conditions. I have an IBM Thinkpad running XP Pro (1.18 GHz, lots of memory) and over the last year it got successively slower and then began to fail without ever having been exposed to the open internet (absolutely no viruses or spyware, and I checked). I don't even use it for e-mail. Eventually, a complete restore and climb back through all the updates brought it back to life.

In the meantime, besides my regular machine, I ran 10.2.8 on on an old Beige G3 (XPostFacto) and it was still snappier at the end of a year. My regular machine, a goosed up B&W G3, running 10.3.9 is too.

Moral of the story. For a few weeks, XP Pro is snappier, but it's all downhill from there as every upgrade slows the machine down a bit.

One of the reasons XP Pro is so snappy now is that I have not installed any of the service packs. Instead, I've just committed myself to using it behind my own firewall and those of my clients (for whom I have the machine in the first place).