Performance problem in Word 2003? (Word 2003)

Over the last year I have used Word in three different configurations: Word 2000 on a 700 MHz desktop machine, Word 2003 on a 2.8 GHz laptop machine, and Word 2000 on a 2.8 GHz desktop machine. The Word 2003 configuration seemed to run VBA macros slower than the other two by a factor of perhaps 10. I did not have a great deal of time to spend isolating the problem, but it seemed to have something to do with setting or clearing bookmarks.

Is anyone else familiar with this problem? Is there a workaround? I can't stay with Word 2000 forever, but I can't live with the type of performance Word 2000 3 has given me.

Re: Performance problem in Word 2003? (Word 2003)

I think you are going to have to do some more investigation before anyone can give you real help.

When I migrated some Macros from Excel 2002 to Excel 2003 I discovered that setting the .Hidden attribute of a row was very slow. When I explained this, someone quickly told me that this now caused a recalculate event. If you can identify exactly which lines of your VBA are taking longer then we may be able to "guess" why.

Re: Performance problem in Word 2003? (Word 2003)

I tried to track the problem down earlier this year, but found nothing definitive. Some of my experiments suggested that the problem was associated with either setting or referencing bookmarks. Others suggested that at least part of the problem was not associated with any particular part of the code, but with the process of running macros itself.

Typically one of my experiments would narrow the problem down to a large loop that executed many times and performed several operations. The loop would take much longer to complete on one machine than on the other, but a single iteration took too little time to measure, so identifying an individual slow operation was out of the question. To pursue the matter further I would have had to write special test code, and I did not have time for that.

Now that my classes are over for the summer I have more time to experiment, but I have nothing to experiment with. The laptop computer was on loan from my school as a disability accommodation, and had to be returned at the end of the semester. It will presumably be restored to me at the beginning of next semester (late in August), but once classes resume I will again have little time to experiment.

Re: Performance problem in Word 2003? (Word 2003)

Could it be that when you upgraded the VBA code to various versions of Word it code got mashed <img src=/S/bash.gif border=0 alt=bash width=35 height=39> ? I had a similar problem and, following advice of a post here from Charlotte which I now cannot find, exported all the VBA objects (forms, modules, classes) and then started a new document and imported them. Then recompile the project.

Re: Performance problem in Word 2003? (Word 2003)

Gwenda: I'm not sure what to make of your suggestion, because I never knew it was possible to compile a VBA program. It's strange, since I used VBA intensively for several years, and have poked into many of its obscure corners.

I looked in the VBA editor's help file and found nothing under "compile" or "compiler," although I did find one baffling reference to conditional compilation directives. I was about to reply that you misunderstood something when I looked at the Debug menu, and found it right there at the top: "Compile Project." I still have no clue to what it does, though. I Googled it and found numerous references to compiling VBA code, but no explanation.

I guess my final answer has to be that I do not see how recompiling the project could help, since I never compiled it in the first place, not knowing that such was possible.

Perhaps exporting and re-importing all the modules would help, and I can try that when I get the laptop machine back. I hope I can get a better understanding of why I'm doing it first, since it will be a lot of work. The program has 7 modules, 4 class modules, 11 forms, and about a dozen custom properties that would have to be redefined. It sounds like about an hour's work, assuming nothing goes wrong.

Re: Performance problem in Word 2003? (Word 2003)

The first time you run VBA code after it has been created or modified, the module containing the bit of code is checked for syntactic correctness, and the some information is generated that will make the code run more efficiently; this information is stored with the document and will only be regenerated if the code is modified. As you run more code, more of this information will be generated. The Debug | Compile Project menu option forces VBA to do this for the entire project at once; one advantage is that you'll be warned about syntactical errors anywhere in the code, and that code execution will be slightly faster since all runtime information has already been generated.

However, over time this runtime information may become polluted; that's why it may help to export all modules etc. and to re-import them. This forces VBA to look at them afresh. There is a utility that will do the export and import for you: see this page on the Word MVP site; the download is at the bottom.

Re: Performance problem in Word 2003? (Word 2003)

Hi Hans,

Any chance that this might be a problem with early binding? I notice that two of the PCs run Word 2000, whilst the 'problem' one runs Word 2003. If the macro code uses early binding to refer to a library from Office 2000, would performance suffer when run in an Office 2003 environment?

Re: Performance problem in Word 2003? (Word 2003)

I don't think so - refererences automatically resolve themselves if you move "up" in versions; moreover, the original poster doesn't mention using references to other applications. If he does, it might be worth a try, it shouldn't take too long to modify a copy to use late binding.

Re: Performance problem in Word 2003? (Word 2003)

I just returned to this thread and found several messages newer than the one which begins "The first time you run VBA code ..." For some reason the administrative program did not notify me when they were posted.

I know what early binding is, but I don't know anything about how it relates to VBA -- since the language uses just-in-time compiling, the term has no clear meaning to me in this context. I am indeed using references to two other programs, Internet Explorer and Eudora. However, the program's slowness is most evident in parts that make no use of those references whatever. (I am not implying a negative correlation; as far as I can see, though, there is no correlation.)

If this still sounds like something I should investigate, please explain further, and I will look into it when I get the laptop computer back in August.

Now, here's what I came back to post: it occurred to me that the versions of my template and data file which are working perfectly on my new tower machine (Windows XP, Word 2000) are the latest versions, which were running so slowly on the laptop (Windows XP, Word 2002). It seems to me that if the files got corrupted in the move from my old tower machine (Windows 2000, Word 2000) to the laptop, they would stay corrupted, and would still be running slowly. Does this make sense? If so, the corrupted-file hypothesis would appear to be disproved.

Re: Performance problem in Word 2003? (Word 2003)

> For some reason the administrative program did not notify me when they were posted.

I think you only get notified of direct responses to your post, not responses to other peoples' posts. However, I don't use the notification/reminder/favorites features enough to know the exact pattern.

Anyway, early vs. late binding in this context means whether a DLL reference is hardcoded into the template:

<UL><LI>Early binding = yes, set in the VBE's Tools>References dialog
<LI>Late binding = no, no reference is set[/list]For late binding, you declare object variables rather than particular types of objects, and use CreateObject to instantiate them using an identifier that remains the same across versions, such as Word.Application (these must be in the registry or the code fails). This approach eliminates the possibility that a hardcoded DLL name causes a problem with resolving a reference when that DLL is not found, but it is somewhat slower than early binding.

Re: Performance problem in Word 2003? (Word 2003)

>For late binding, you declare object variables rather than particular types of objects,
>and use CreateObject to instantiate

OK, I understand now. I'm using late binding. I don't recall whether I ever knew that early binding, as you describe it, was possible -- if I did, I clearly thought late binding was preferable, and I gather you would agree.

Re: Performance problem in Word 2003? (Word 2003)

I prefer early binding whenever possible, but sometimes you need late binding. In such cases I develop using early binding, taking care not to use New. At the last possible moment, I replace the early binding declarations by "Dim ... As Object", and replace all symbolic constants by their values. Then, I remove the reference(s).
That way, I can profit from IntelliSense, and yet create late binding code.

Re: Performance problem in Word 2003? (Word 2003)

For one of the (surprisingly) more coherent explanations of early binding (aka V-table binding) and late binding (not to mention a "hybrid" type of late binding known as DispID binding) and a comparison of each, see MSKB 245115:

"Binding is a process of matching function calls written by the programmer to the actual code (internal or external) that implements the function. It is done when the application is compiled, and all functions called in code must be bound before the code can be executed." As for question, "Which Form of Binding Should I Use?" FWIW, "Microsoft recommends early binding in almost all cases. However, there may be reasons for choosing late binding." (Emphasis added.)

"Early binding is the preferred method. It is the best performer because your application binds directly to the address of the function being called and there is no extra overhead in doing a run-time lookup. In terms of overall execution speed, it is at least twice as fast as late binding.

"Early binding also provides type safety. When you have a reference set to the component's type library, Visual Basic provides IntelliSense support to help you code each function correctly. Visual Basic also warns you if the data type of a parameter or return value is incorrect, saving a lot of time when writing and debugging code."

In reference to Office Automation: "Office applications will typically expand their interfaces to add new functionality or correct previous shortcomings between versions. If you need to automate an Office application, it is recommended that you early bind to the earliest version of the product that you expect could be installed on your client's system."

For the reasons cited above, I prefer to use early binding whenever practical. If late binding must be used, I do what HansV suggests, "cheat" by setting reference to the server application so that Intellisense, etc may be used to write code, then before finalizing, remove reference to type library, and replace any symbolic constants with numerical values, etc (adding comments to indicate which constants are represented by the numerical arguments).