>>In my experience, I haven't noticed any performance loss when using WSH.
>
>You're not pushing hard enough...

Probably you're right. I've never used it for intensive tasks.

>>Did you try to keep it in memory all the time? By adding it to the well known dlls? Or by keeping an object in the Session object?
>
>In a session object? That's a no-no for scalable applications...

Sorry, I meant the Application object, not the Session.

It has nothing to do with scalability. If you want to use WSH, it has to be loaded at least once on each server.
If you can force it to load only once, it should be perfect. So, if you keep on object from wsh alive all the time,
it should load wsh only once (I'm not quite sure, but it worths a try). The only purpose of this object would be
to keep wsh loaded. For everything else, use newly created objects.

Something like:

<%
on error resume next
'-- Avoid creating the object each time
Application.Lock
set z = application("x")
if err.number <> 0 then
	set application("x")=server.CreateObject("Scripting.FileSystemObject")
end if
Application.Unlock
set y = application("x").GetFile("d:\inetpub\wwwroot\default.asp")
call y.Copy("def.asp", true)
response.write "ZZZ"
%>

>I don't think well known dlls load COm objects into common memory.

I don't know. But it's worth it to try it. The objects may not be in common memory, but if the dll is used from
common memory (to load the code), it should be all right.

>IAC, the real overhead in COM type applications is the reload more than the footprint.

Right. In both cases the wsh may be loaded only once, but I did not test it.

Vlad