Scripting Type Library Constant Injection Performance Characteristics, Part Three

No SxS love from the Windows Script Host? « KK’s Blog

No SxS love from the Windows Script Host? « KK’s Blog — Sat, 25 Aug 2007 19:41:45 GMT

PingBack from http://kobyk.wordpress.com/2007/08/25/no-sxs-love-from-the-windows-script-host/

re: Scripting Type Library Constant Injection Performance Characteristics, Part Three

Eric Lippert — Tue, 12 Jul 2005 04:16:51 GMT

Hey James,

Use the Clone method. When you clone an engine, all the persistent compiled code blocks are shared between the original and clone, so the cost of recompilation disappears.

I've got a brief description of how ASP caches script engines and threads here:

http://blogs.msdn.com/ericlippert/archive/2003/09/18/53046.aspx

re: Scripting Type Library Constant Injection Performance Characteristics, Part Three

James Hugard — Mon, 11 Jul 2005 20:39:23 GMT

> but I'm surprised by the claim that it is only two orders of magnitude slower.

Hmm... when I originally timed the difference, I had not even considered runtime costs.

The quoted two-orders of magnitude was for the parse-time of several hundred constants, not execution time. Since we load those constants for every script, and since we load thousands of scripts thousands of times per run, constants loading was one of the more expensive items at one point.

On top of that, ATL in VC6 has a bug which occasionally causes simultanious type library requests to fail (I can find the KB number, if interested).

For those reasons, I moved us to script-based constants rather then importing multiple typelibs.

Today, our most expensive item is parse time, which runs about 4 times our average script execution time. We have thousands of lines of script include files that get parsed for every script.

re: Scripting Type Library Constant Injection Performance Characteristics, Part Three

James Hugard — Mon, 11 Jul 2005 20:24:37 GMT

> and the ASP engine caches and reuses the compiled state over
> and over again without doing a recompilation

How, pray tell, can I do this wonderful thing in my own code? Recompilation is one of the most expensive things in our current script host.

re: Scripting Type Library Constant Injection Performance Characteristics, Part Three

Bob Riemersma — Sat, 09 Jul 2005 22:40:04 GMT

Alas, ASP pages and even intranet client-side DHTML is not the only case where VBScript and for that matter lots of typelib constants come in handy.

WSH scripters can cope due to the <reference> tag available in .WSF format script source files. Then again, few WSH scripts engage in truly long-lifetime multiple-use activities. Here you still get the typelib penalty with little payback... but in such cases performance isn't paramount anyway. The odd long-running WSH script still gets the benefit.

Where the developer is truly in a bind is with HTAs. Since there isn't any clean support for loading typelibs in IE, the HTA developer is just screwed. Yet a given HTA might have as long a lifetime as any compiled application run on the desktop. The execution model doesn't resemble ASP pages or typical web pages built with DHTML. It's a lot more like a VB forms program.

So an HTA developer using ADO or somesuch bag of components is reduced to importing long lists of Consts... or worse yet placing magic numbers all over the place.

The result is that both HTAs and WSH scripts (since nobody writes .WSFs) end up laced with magic numbers, resulting in confusing code and maintenance headaches. The .WSF-aversion probably stems directly from the fact that IE can't use this script source format.

So a design decision (no typelib support in IE) meant to protect Johnny-no-teeth means none of us can have steak. "Silly wabbit, script is for kids" seems to be the message here.