We have an ASP script that creates an Excel.Application object (not
visible), fills a blank worksheet with data, saves it, then runs an
XLM macro from another worksheet.  Under NT / Excel 97, the macro used
about 50-60% of the CPU.  Under W2K / Excel 2K, it uses only 5-10%,
with System Idle taking up most of the remainder.  Until the macro is
run, Excel is running at 50-60% CPU, as we'd expect.  We've installed
all the latest service packs for Windows and Office (we've seen
Q215764, "XL2000: Excel4 Macro Runs Slowly When Excel Is in the
Background").

Note: We've checked in perfmon for disk access slowing the macro down,
nothing there. Changing the priority of the process doesn't make any
difference.  The memory is fairly static at 15 Mb, it's not that. 
Changing the user Excel runs as makes no difference.  Making the Excel
application visible makes no difference.

If we run the macro in the foreground on the 2000 machine, it runs
very quickly, as we'd expect.  The problem only comes when Excel is
invoked from our ASP script.

How can we get our macro to run at with its correct share of the CPU?

---

Clarification of Question by prbt-ga on 09 Jul 2002 10:14 PDT

Also: the slowdown doesn't just happen when creating the component
through ASP.  We wrote a cscript (.vbs) that mimicked the pertinent
points of the ASP script, and this runs at 5-10% also.

Any chance a virus program is running
and is scanning the macro when it is
run?

If it only happens when run with the
ASP script... could it be that?

-AI

alienintelligence: No, no AV software.  We *did* have Norton running,
but it was switched off very early in the game.  Thanks for replying,
though.

Ok, have you set up anything to monitor
processes? Mainly what I'm wondering is,
could the ASP script be holding something 
up, waiting for the Excel bit to finish?

Also, have you tried running it on another
computer?

-AI

AI: No, we've not tried it on another 2000 box yet. That's our next
step, though we've no reason to believe we won't get the same results.

To explain the process a bit further:  ASP opens Excel.  It fills a
blank spreadsheet with data from a database (thru ASP).  Up to this
point, Excel is getting 50-60% CPU. Then another spreadsheet is opened
from the filing system, and an XLM macro from it is run - it's at this
point we get 5-10% CPU.  After the macro is run, Excel is closed.

Now, the macro does things like opening up other spreadsheets,
thousands of calculations, saving spreadsheets.  Under NT/Excel 97, no
problem, it gets 50-60% CPU.  Under 2000, 5-10%.  (If we run it
'standalone', not through ASP, we get 50-60%).  So the problem looks
to be ASP, but would ASP deliberately throttle the CPU time of a
process it had no involvement in?

Points:  1) There are no links across the network in any of the
spreadsheets, it's all local.  2) Someone suggested opening up all the
relevant spreadsheets FIRST in ASP, not letting the XLM macro do it -
no difference.  3) We've run it under plain Excel 2000, then Service
Release 1, and then Service Pack 2 - no difference. 3) Someone else
suggested checking the regional settings - they WERE different between
the NT and 2000 boxes, but changing them made no difference.

What would be some good things to check out in perfmon to try and
determine what's going on?

PS Just re-read your comment, I mis-understood it the first time: No,
we've got nothing set up to monitor processes.

I would trim ASP code. Make it bare bones.
Leave in only the part that causes problems.
See if it still happens with the slim code.

Maybe there is something that resets in NT
or idles but doesn't reset by default in 2000?

If the code trim doesn't work, try launching
a different app like notepad instead. Fill it
with your data, or whatever part of it you
can. See what happens to the processes then.

Speaking of processes, I haven't downloaded
this, Process Explorer, but it looks promising:
http://www.sysinternals.com/ntw2k/freeware/procexp.shtml

-AI

This has now been sorted.  The problem?

Excel.Application.Visible = False

We changed it to 'True', and everything works fine now...!