DWScript SVN repository has been fleshed out during the last days:
- there are now several samples, an half-decent collection of unit tests, and the “classes” library module which offers basic containers.
- code should be compatible with from Delphi 2009 to Delphi XE.
- some more optimizations got enabled.
- timeouts for script execution are now specified in milliseconds (used to be seconds).
A 7zip snapshot of the SVN is available here and will serve as preview.
On a side note, I re-ran the informal performance tests: they are now running about twice faster than during my previous post. Also, one of the demos is used as a floating-point benchmark, and renders a Mandelbrot fractal (once with Delphi, once with DWS). It’ll serve as reference for future progress and help detect performance regressions.
Nice work! Congratulations!
Thanks for having create a snapshot, this is very handy.
Could you put the performance tests results in some text file in the repository? I like the fact that you created new classes of data to handle directly integer, string and double types, instead of using Variant conversion.
Tests sound right to me. Nice new feature for avoiding regressions.
Perhaps some more comments should be needed, at least to detail what’s the purpose of every class. In all cases, the code is easy to follow, like always with DWScript. But it’s always a bit memory consuming. Every item (not only variable, but every code op) in DWS creates a class instance, several more than once. This was always a big performance issue, when compared with RO Pascal Script, which uses a virtual machine.
I noticed that the data stacked storage uses Variants, which sounds like some memory and performance waste. Shouldn’t it be possible to have multiple stacks, specialized per data? i.e. a Variants stack, one for Integers, one for Strings, one for doubles
Congratulations, indeed.
Another thing: I noticed some memory leaks in previous DWS implementations.
Did you test that no memory leak occur? If DWS is used in a long-time running server (which could be the case, even without the web we could imagine coding the business logic in DWS instead of compiled Delphi), any memory leak is to be avoided, like hell.
Perhaps it could be added in the testing mechanisms, so that no running test would create memory leak.
Classes only matter as far as memory usage and function calls conventions do, performance-wise, the expression tree behaves like a jump-table based virtual machine interpreter, it’s just that everything is expressed in terms of VMT pointers.
The performance issues came mostly from the Delphi poor handling of functions returning values of Variant, String or Double type (hence why the code now leans towards using procedures with var params, that’s not ideal, but it drastically limits the amount of mess the compiler can generate).
FWIW, the Mandelbrot code (with the SetPixel line removed, because I don’t know how to expose it most efficiently in PascalScript) runs in 280ms with DWS, vs 7330ms in PascalScript. Though, I’m no user of PascalScript, so you may want to check by yourself and see if I missed some options.
Strong typing would providing a plus, but for memory usage, gains would probably be limited as scripts IME don’t use that much of stack space. An area that could benefit more in terms of memory would be strongly typed arrays (which still use variant arrays), though IME they don’t see much use in scripts (specialized classes being preferred).
As for memory leaks, we have quite a few scripts in server-side usage, and I used some for heavy duty simulation tasks (hundredths of executions per seconds) without running into issues. It could be the issues got solved sometime ago, or that we didn’t use the problematic script features. If you’ve got some sample exposing a loss, don’t hesitate to send it or post it in an issue on the googlecode tracker.