Informal DelphiWebScript performance tests

I’ve made some informal performance tests on DWS vs PascalScript vs Delphi.

The PascalScript version was downloaded yesterday, though when compiling, I got many warnings hinting its code hasn’t been fully upgraded to Unicode and D2009, so maybe it wasn’t the latest version? I’m not a user of PascalScript, so if anyone want to chime in, feel free!

The script I used for testing was something like

var s, i: Integer;
for i:=1 to 1000000 do s:=s+i;

with only minimal syntax adaptations to get it running and compiling in the various environments. For PascalScript, I tweaked the “sample1” project to run the script, so maybe there were some optimization options not active? If so, let me know!
The result timings on my machine were (including compilation and execution, except for Delphi):

Delphi: <1 msec (using 32bit integers), 1.5 msec (using 64bit integers)
DWS2 revival: 150 60 msec in D2009 (using 64bit integers)
DWS2 vanilla: 420 msec in D7 (using 32bit integers)
PascalScript: 1860 msec in D2009, 1490 msec in D7 (using 32bit integers)

Note that in DWS2 revival, integers are 64bit integers (more on that and other changes later).

I then redid the test using a double precision float for the “s” variable: Delphi goes up to 15 msec, DWS2 revival increases to 180 95 ms (vs 670 ms for vanilla), PascalScript results were unchanged.

Last test consisted in moving the “s:=s+i” to a function, to measure the call overhead. Delphi laughed at me and stayed with roughly the same figures, PascalScript went up to 3000 msec, and DWS2 revival took a hit to 1000 msec. Function calls are indeed a DWS area with still some simplifications and optimizations potential 😉

As for the re-release time-frame, I’m waiting to hear from the original maintainers, as well as removing a few dependencies to make it into a standalone library (currently the compiler itself is standalone, but the DWS library equivalents of system & sysutils units aren’t).

edit 2010-09-01: following a round of cleanup and optimizations, figures for DWS revival are now 60 and 95 msec for 64bit integers and floats respectively.

9 thoughts on “Informal DelphiWebScript performance tests

  1. If the point is a performance comparison between Delphi scripting components then it would be nice to include PaxCompiler, as I suspect it is the fastest.

  2. Actual version of PascalScript should be compatible with D2009 and D2010, try downloading “Summer 2010” version from or get current version from SVN, see

    PascalScript precompiles source code into some sort of byte-code, which is interpreted later during execution. Did You do timing with this precompile step or only execution? I thought, that with such simple code PS should be much faster…


  3. @Daniel Mauric
    PaxCompiler gives me 31 msec for both integer and double, so that’s better, but still not quite into Delphi-like native execution speed. Also, AFAICT, PaxCompiler is closed-source.

  4. @Charles Ardour
    Summer 2010 is the version I downloaded, it worked, but it gave me warnings under D2009 for “sample1” f.i., is that normal?
    As said in the post the timings include compilation, however for such a small amount of code, it should be pretty much negligible.

    FWIW PascalScript spends most of its execution time in LStrArrayClr, followed by DoCalc, DoBooleanCalc, RunScript and ReadVariable (the LStrArrayClr overhead is parasitic, but unsurprising given the implementations of DoCalc & DoBooleanCalc f.i.).

  5. @Eric
    Interesting test.
    I used DWS a lot a couple of years back. Since the title is now “revival” i guess it has been taken up again? It was sort of defunct for a while. I used DWS in two commercial products as a driver system. The app downloaded script files for different purposes. Worked great!

    Anyways, im a bit curious about pascalscript. Since it precompiles into a byte buffer i find it hard to believe that paxcompiler should outrun it by such a margin? I havent checked out pax yet — does it compile to buffers as well? Or is it a line by line translation?

    I doubt you will ever get anything like native speed.
    That would require a JIT (just in time) compiler, which translates into bytecode patterns and then converts this to native x86 assembler. This is what .NET does. The compiled segments are then stored on disk in the GAC (general assembly cache).

    Do you have any reports that show the differences, but also with the use of graphical methods, streaming etc.?

  6. Anyways, im a bit curious about pascalscript. Since it precompiles into a byte buffer i find it hard to believe that paxcompiler should outrun it by such a margin?

    From what I see in the source code, PascalScript compiles to p-code (not native code), which is then interpreted via large procedures made of nested “case” statements and branches. Unless there is a different runtime than the one I’ve seen, PascalScript will be nowhere near native performance, and should theoretically lag DWS virtual expression tree too (especially when branch mis-predictions will kick in).

    As for DWS performance, my personal aim is for “good enough”, so that the performance bottlenecks will be in the code invoked from a script, rather than in the script itself. And the overarching needs are for a light, embeddable, self-contained, sandboxed, easily maintainable script engine.

  7. I found this post and wanted to make a short comment about paxCompiler. It actually compiles to machine code, so it will be faster overall. On average it’s about 3-4 times slower than optimized Delphi code. We use it as the core scripting system in our game engine and I can confirm that it works very well. I’ve compiled the AstroBlaster demo paxCompiler and was very impressed with it’s speed and execution.

  8. I’ve tried every scripting engine out-there with no exception, and I found that PAXCompiler has good inner-structure and absolutely great features, but one thing that makes me worry alot with PAX, that its maintained by a single developer and that may crash my projects if he quits or else, I tried to use RemObjects script but I was always comparing the facilities of PAX with PS and finally I went back to PAX with a Hugh risk.

  9. From my point of view, DWS was never defunct. I use it, in its role as a webscripting language, as the engine that drives a dozen sites. And as a reporting tool for all our internal applications. In the eight years I have been using it, I must have written close to 1,000 scripts. Some I have thrown away – although it is great for that purpose – but about 600 of them are still in regular use.

    The great benefit of DWS over e.g., PHP is that it can easily be extended. Need a function from say, DateUtils? Or SysUtils? Easy! Write a wrapper and add it to the runtime library. And if you know Delphi, you know DWS.

    Need support for a database? Same thing! You are not required to use MySQL – although you can if you want. If you can open the database in Delphi, you can write a wrapper class to do the same in DWS.

Comments are closed.