Very slow running VBA in Office 2003/XP

[Sue D]

I have a Word macro, that moves data via EXCEL to format data into tables in
a Word document.
This macro has been develped over the years upgrading from Word 97 to 2000
and now 2003 running under Windows XP. It has suddenly started to run very
slowly on one macine we have it installed on. On an original test PC it only
took 1 .5 minutes but the same data on the production PC it takes 8 minutes.

The only other evidence I have is from looking at the Task manager
1) Test PC runs the macro at 100% CPU while the Production PC runs at 50%
2) Commit Charge Test = 159M/1228 Production = 225M/2227M
3) WinWord.Exe Test = 29284K Production = 35788K versus

I am not technical, so do not know how to follow up on this.
But it seems strange that what our technical department claim to be 2
similar configured PCs, can produce such different results.

 

[Cindy M -WordMVP-]

Hi =?Utf-8?B?U3VlIEQ=?=,

Can you describe how the Word document is generated? Is it created from a
specific, centrally stored template? From a local template? From a local
document?

If you say "we just automate Word, using Documents.Add", then try renaming the
Normal.dot template on this machine to NormalOLD.dot and test again. If things
now run at a normal speed, then the former Normal.dot was damaged.

Normal.dot is used to store user-specific customizations (AutoText,
AutoCorrect, Toolbars, Styles, Macros). In order not to lose these, you can use
Tools/Templates and Addins/Organizer to copy everything except the AutoCorrect
to the new Normal.dot. There's a special macro in the Word 2003 Support.dot
template to backup/restore the AutoCorrect entries.

I have a Word macro, that moves data via EXCEL to format data into tables in
a Word document.
This macro has been develped over the years upgrading from Word 97 to 2000
and now 2003 running under Windows XP. It has suddenly started to run very
slowly on one macine we have it installed on. On an original test PC it only
took 1 .5 minutes but the same data on the production PC it takes 8 minutes.

The only other evidence I have is from looking at the Task manager
1) Test PC runs the macro at 100% CPU while the Production PC runs at 50%
2) Commit Charge Test = 159M/1228 Production = 225M/2227M
3) WinWord.Exe Test = 29284K Production = 35788K versus

I am not technical, so do not know how to follow up on this.
But it seems strange that what our technical department claim to be 2
similar configured PCs, can produce such different results.

Cindy Meister
INTER-Solutions, Switzerland
http://homepage.swissonline.ch/cindymeister (last update Jun 8 2004)
http://www.word.mvps.org

This reply is posted in the Newsgroup; please post any follow question or reply
in the newsgroup and not by e-mail

 

[Sue D]

Cindy
Thanks for your interest in my problem.
My Word document is created using Document.Add in a locally stored template.
I will try renaming Normal.dot and see what results I get.

 

[Sue D]

Cindy
I have now run with renaming the Normal.dot template, but it made no
difference.

Another clue may be that I notice, in debug, the macro is painfully slow at
moving through the cells of large tables in the document. This is not the
case when procesing the same data on the test PC.
Regards Sue D

 

[Cindy M -WordMVP-]

Hi Sue,

I've been thinking and thinking about this, and no light bulbs are popping
up... The other "test parameters" I'd usually use would be to start Word, and
then Windows, in Safe Mode and see if that makes any difference.

The latter should be easy enough for you. Whether you can reasonably to the
former depends on whether/how your code is accessing Word? Is it creating a
new Word application? Or is it using an existing one? Or can you change it to
use an existing one and start Word manually (hold Ctrl while starting it)?

I have now run with renaming the Normal.dot template, but it made no
difference.

Another clue may be that I notice, in debug, the macro is painfully slow at
moving through the cells of large tables in the document. This is not the
case when procesing the same data on the test PC.

Cindy Meister
INTER-Solutions, Switzerland
http://homepage.swissonline.ch/cindymeister (last update Jun 8 2004)
http://www.word.mvps.org

This reply is posted in the Newsgroup; please post any follow question or
reply in the newsgroup and not by e-mail

 

[Sue D]

Thank you for continuing to ponder my problem. I am still trying to resolve
it, with one of our technical staff building a stripped down PC to mirror the
one we are having problems with.

I need to ask you further on your last post - I do not understand what you
mean by
I understand Word to run under Windows. So Windows must be started first (F8
at Restart to enter Safe Mode) than Word can be started.
Or do you mean run “Winword.exe /a “ under normal boot-up of Windows.

Sue Dilworth
Project Leader
www.AGCOCorp.com

 

[Sue D]

Cindy
Think no longer - my Technical support guy has just told me he has resolved
the problem. It was caused by some additional security applied by the McAFee
Virus Scanner, which was being tripped when large macros were running. This
more advanced level of security was not applied to my development PC.
Irrespective, many thneks for your concern
Best Regards
Sue Dilworth
www.agcocorp.com

 

[Cindy M -WordMVP-]

Hi =?Utf-8?B?U3VlIEQ=?=,

I need to ask you further on your last post - I do not understand what you
mean by

I understand Word to run under Windows. So Windows must be started first (F8
at Restart to enter Safe Mode) than Word can be started.
Or do you mean run “Winword.exe /a “ under normal boot-up of Windows.

I'm sorry. I meant to first try Word in Safe Mode and, if that gives no
results, try Windows in Safe Mode (with Word starting normally). If either
shows an effect, you can narrow down the search to either an Add-in in Word, or
something in the Windows configuration.

Cindy Meister
INTER-Solutions, Switzerland
http://homepage.swissonline.ch/cindymeister (last update Jun 8 2004)
http://www.word.mvps.org

This reply is posted in the Newsgroup; please post any follow question or reply
in the newsgroup and not by e-mail

 

[Cindy M -WordMVP-]

Hi Sue

my Technical support guy has just told me he has resolved
the problem. It was caused by some additional security applied by the McAFee
Virus Scanner, which was being tripped when large macros were running. This
more advanced level of security was not applied to my development PC.

Thank you very much for reporting back This all helps the next "poor soul"
who happens along with a similar problem.

Cindy Meister