VBA Early vs Late binding - real life performance differences

Question

I\'m writing a robust Word macro that will be used on wide range of Words on several different machines.
I have red on many expert VBA forums, that early binding i

Answer 1

Not sure this should go as answer but hey,

Early binding is preferred for development work (speed and intellisense). Late binding is frequently used for distribution for exactly the reasons you mention. Far safer to go with Late binding in production unless you can be absolutely 100% certain of your users set-ups.

To quote from the Word MVP website

Advantages of Early Binding

Your code will run considerably faster, because it can all be compiled up front. With late binding, the code relating to an application you declared as an object has to, in effect, be compiled as it runs.

Because your code can all be compiled up front, debugging is far easier – select Debug + Compile, and the compiler will be able to spot syntax errors which would have been missed had you used late binding.

You have full access in your project to intellisense (type a keyword and a dot to get a popup list of properties and methods supported by that keyword, select one to insert it; type a keyword and press F1 to launch the Help topic on that keyword).

You have full access to the application's object model via the Object Browser and VBA Help.

You have access to the application's built-in constants. For instance, if you are automating Word from Excel, you can use:

Dim objWord As Word.Application 
Set objWord = New Word.Application 

With objWord 
    .Visible = True 
    .Activate 
    .WindowState = wdWindowStateMaximize 
    .Documents.Open ("c:\temp\temp.doc") 
End With 

Furthermore, when you type

.WindowState =

you'll get a pop-up list of the supported constants, and can simply pick wdWindowStateMaximize from the list.

If you used late binding, you would need to use:

.WindowState = 1

.. and you would need to know (by looking it up in Word's Object Browser) that the value of the constant "wdWindowStateMaximize" happens to be 1.

All this makes programming using early binding immeasurably easier than using late binding.

Advantages of Late Binding

The main advantage is that code which uses late binding is more certain to be version-independent

If you set a reference in a Word 97 project to “Microsoft Excel 8.0 Object Library”, then the project will run OK on a machine which has Office 2000 installed. Word 2000 changes the reference on the fly to the “Microsoft Excel 9.0 Object Library”.

But as they famously say, YMMV. Problems have been found in certain circumstances. For instance, if you run a Word 97 project containing a reference to the Excel 8.0 object library on a machine with Office 2000 installed, it will run OK, but you may get the occasional “cannot open macro storage” error unless you save the project in Word 2000. If you do save it in Word 2000, the reference will change to the Excel 9.0 object library.

So if you use early binding and support a mixed environment, it may be safest to create separate Word 97 and Word 2000 versions of your addins, despite the maintenance overhead.

The more references your project contains, the larger the file size and the longer it takes to compile.

Some programming environments don't allow you to create references to another application.

If you really want to start delving into COM objects, v-tables and the like maybe start with the following reference:

References:

1. Microsoft Blurb: Using early binding and late binding in Automation