(re: late binding of FSO)
Here I'm a little skeptical. When you write
Dim FSO as Object
You enable FSO to be ANY object, meaning that one moment it can be a FileSystemObject and the next moment it can be a form, textbox, combobox or whatever - all these changes in the same loop. Therefore I suspect that the runtime will need to keep rechecking the "FSO" to verify that the current set of properties and methods is the same.
Er, what? If you keep a global object variable, and initialize it once, there will be no checking of properties or methods -- the object will already by initialized, just as it is after the first use with early binding.
As to looping, you won't be re-initilializing the FSO inside the loop, so there's no chance of it getting unassigned.
This seems to be what Microsoft is stating:
Each time you invoke a property or method with late binding, Visual Basic passes the member name to the GetIDsOfNames method of the object’s IDispatch interface.
http://msdn.microsoft.com/en-us/library/aa241755(VS.60).aspx
Microsoft did not say, "This only happens once at inititialization." Rather they said, "EACH TIME".
Every article I've seen on late-binding to date says that it's slower. I've never seen an article that says, "It's only slower at initialization." Please feel free to show me some articles that prove your point.
Well, it entirely depends on what you're doing. Back in the day when I was programming Outlook for the first time (1998), it was quite clear that operations that a user was doing were not slowed down by initializing via late or early binding. But if I didn't cache the Outlook application object variable and initialized it each time I wanted to use Outlook, it took a very long time for each operation. Once initialized, there was no noticeable difference for a human being (though no doubt if one wanted to benchmark it, one could have found a difference).
My point is that the initialization time of the external application is by far the largest performance drain in regard to automation. Perhaps if you're doing something in a loop that constantly retrieves properties from your OLE object then it could make a difference. I can't realistically conceive of such a loop with the FSO.
FWIW, I only use the FSO for those things that VBA itself lacks. I never use it in place of Dir() or any of the file copying/renaming commands in VBA. Indeed, about the only time I use it is to check network availability. I actually do sometimes call that in a loop, but it takes vastly longer to check the network than it takes for VBA to determine the typing of the methods/properties of my FSO object. In that event, any difference with vTable lookup would be swallowed up into insignificance by the time it takes the FSO to actually check for the network.
In other words, the real-world operations of an application are much more important to me performance-wise than the minute comparative slowdowns of having your vTable pre-initialized. You wouldn't worry about optimizing a printing loop too excessively because the printer itself is going to be the performance bottleneck. Likewise, I'm arguing that in the vast majority or real-world scenarios, the performance hit of that vTable lookup is going to be completely insignificant compared to user actions and other operations (such as the FSO waiting to get data from the file system).
I'm sure there are scenarios where the difference could be noticeable to an end user, but in general, my argument is that those situations are so rare as to not be relevant to the question of whether to use late or early binding. The weaknesses of early binding are quite real, and completely underplayed by the cited article.
In other words, in my opinion, except for the three default Access libraries, all other libraries should be used with late binding BY DEFAULT, until performance issues indicate a need for early binding. And the need for that performance will pop up only in the rarest of circumstances.
I see it as a tradeoff between portability in all cases with late binding and performance in a minuscule number of cases with early binding. To me, the proper tradeoff is quite clear (especially with MDEs, where references can't be fixed up on the fly).
