Re: String to int conversion

Tech-Archive recommends: Fix windows errors by optimizing your registry


"Al Dunbar" wrote:

Since vbscript is an interpreter rather than a compiler,

Sorry, Mr. Dunbar, but you are quite wrong.

VBScript code *IS* compiled--into a byte code with tokens just such as I
showed.

Please trust me on this. I worked at ChiliSoft (which was then bought by
Sun) and we licensed version 3 of both VBScript and JScript from Microsoft.
Yes, the C++ source code. We ported it from Windows to Unix and Linux and
even the IBM Mainframe (yes, I did that one...even to handling EBCDIC
characters and the IBM Mainframe's non-ANSI floating point arithmetic).

As inefficient as VBS is, it would be an order of magnitude or more slower
if it were a "true interpreter." Heck, even Microsoft's QBASIC (of 1990's
vintage) wasn't a "true interprete."

So it is the byte code, generated by the compliation process, that is then
interpreted. No different, in principle, than how Java ".class" files can be
executed by a byte code interpreter if you don't have a "JIT" (Just In Time)
compiler available. (And, in fact, early Java implementations *did*
interpret the byte code when in debug mode. Yes, I worked on one of those,
too.) No different than the way that .NET's CLR (Common Language Runtime)
byte code could be interpreted (though I don't know of any such interpreter).

I think you are
pushing it a bit far to suggest that each line of script code will actually
be converted to the equivalent set of native machine code.

I never meant to imply that. I said that the byte codes were interpreted in
a loop (a C++ while loop, in point of fact). As a byte code token is
encountered, it is then "interpreted"--the main line loop is sent off to a
specific chunk of C++ code that performs the operation requested by the
token. And as I said, the *typical* byte code token then requires the
execution of 70 to 90 lines of C++ code. The byte code interpreter is, quite
naturally, a single-stack based system. So tokens such as
push constant
push variable
add [implies add top two stack items & put result back on stack]
are, indeed, simple enough that 70 to 90 C++ lines are adequate. (Some
tokens, such as those that invoke ActiveX methods, will require many more
lines than that, of course!)

For one thing, X
is a variant, a variable type unknown to the underlying machine. For
another, programs that actually consist of machine code, whether hand-coded,
assembled, or compiled, exist in a context that only exists when the entire
program is there. Think of loops and branches: if the machine code you want
to jump to no longer exists because each statement is "compiled", executed,
then thrown away, where should it be branching to?

Again, you are dead wrong. A VBS "file" is compile *as a unit* into a
pseudo-file of byte code. So *all* the byte code is there. And a jump to is
jumping to a known point within that byte code pseudo-file.

In ASP, in fact, it is the byte code form of a compiled ASP page that is
cached by ASP. ASP maintains an LRU (Least Recently Used) cache of byte code
pseudo-files. And if a page is requested before the byte code is evicted
from the cache, then the compilation process does *NOT* need to happen again!
This is one reason why there is no visible penalty for #include-ing large
chunks of code. It is compiled once and, if not used in one particular page
invocation, just sits there in the cache. [You could quite easily prove
this...or I could...if you are still skeptical.]

[Note that none of this is true for ".vbs" files, of course. There is no
place for the byte code to be cached, so they must be compiled each time they
are used. But there is only one VBScript--and JScript--"engine" on any given
Windows machine. The only difference is that the WSH or CSH "driver" just
calls the compiler and then passes the byte-code buffer returned from the
compiler right back into the interpreter. Whereas in ASP, the ASP "engine"
saves the buffer first. Or avoids the compile and just hands over a
previously-compiled buffer.]

All of this accounts for why ASP is as fast as it is! We think of it as
slow--and it is, compared to VB.NET or C# or even Java--but it's not snail
slow, at all.

The gist of my reply is that you are possibly underestimating the number of
actual machine-level instructions that will be executed (in whatever manner)
in order to execute however many lines exist in the script.

Well, now, that might be true. Only because I was trying to err on the
conservative side. But I'd stake my software engineer's reputation that I am
off by less than half an order of magnitude.

But that is a moot point with scripting. I believe that the only way
available to make one's code run faster is to ensure one's algorithms are
the best and most efficient, and to recognize the contribution of other
components that, in addition to adding functionality, also suck up
resources. This includes things like the o/s itself, other tasks and
processes running, intermediary COM objects such as FSO, etc. etc.

Or write using a truly compiled language, of course. But then the other
components won't be any faster. So whether you see a dramatic improvement or
not depends on how much of your time is spent in your own code and how much
in the components.

If a SQL query takes 3 minutes to execute and 100 milliseconds for VBScript
to produce a report therefrom, reducing the VBS time to zero milliseconds
will have no measurable impact on the overall system.

It is interesting to note that, with the exception of this thread and a few
others over the years, there has been very little effort devoted to this
minutae, even from those that could, if they were of a mind, add some
technical info to the discussion.

You just haven't been visiting the same forums I have. <grin/>

No, you are right. Most people don't care about the minutiae.

Bill Wilkinson
ex-Chilisoft
ex-Sun
even ex-MS

p.s.: And version 5 of VBS shows measurable--though not
enormous--improvement over the version 3 I worked on.
.

Relevant Pages

  • Re: String to int conversion
    ... an interpreter produces its results by some other means. ... if it *was* converted in chunks into actual machine code to be ... compiler available. ... in order to execute however many lines exist in the script. ...
    (microsoft.public.scripting.vbscript)
  • Re: sml for newbies
    ... > compiler. ... may give the /impression/ that what you have is an interpreter. ... to machine code and the generated machine code is then executed. ...
    (comp.lang.ml)
  • Re: A stupid post about Intels latest computer chip ( s)
    ... I've heard of forth implementations that run in machine code - define something and the definition is stored as machine code that executes the operations in the definition. ... would that be a compiler, or is it still an interpreter? ... the executable form of a definition in the classical model was a sequence of "compiled" absolute addresses processed by an address interpreter which on some platforms was slightly faster than a CALL instruction. ...
    (sci.electronics.design)
  • Re: compiled open source Windows lisp
    ... >> Compiler, not interpreter. ... All available Common Lisp implementations ... >> compile to machine code. ... > compiler for a virtual machine. ...
    (comp.lang.lisp)
  • Re: Build your own Forth for Microchip PIC (Episode 837)
    ... the unreasonablly small hardware stack size for my particular target. ... You are handcuffed in the sense that you would like to be able to download small amounts of code into ram and execute it. ... because once you do away with the inner interpreter, ... An optimizing compiler isn't a post-processor, it's an *alternative* to another kind of compiler. ...
    (comp.lang.forth)