Kudos to the Firefox 4 TraceMonkey team!

I’ve been quite impressed with the JavaScript floating point performance in FireFox 4, which puts the Delphi compiler to shame. See for yourself this fractal rendering demo:

Mandelbrot Set in HTML 5 Canvas

I’ve made a version of the same code in Delphi XE (source + pre-compiled executable, 331 kB ZIP), and on my machine here, for the 480×480 resolution, where FireFox 4 gets the default view rendered in 124 ms, where the “regular” Delphi version, which is limited to the old FPU, takes about 200 ms…

(more…)

DWScript: objects memory model

Objects memory management in Delphi Web Script is automatic, and you never have to worry about releasing objects in a script if you don’t want to. However, there are elements of manual memory management in DWS which provide greater control, and allow to enforce correctness of object-lifetime.

For instance, in DWS you can avoid the issue that is present in traditional GC-based environments, where references to long obsolete objects can still live in memory, and can still be invoked without triggering exceptions.

Automatic Memory Management

Up to and including version 2.2, the garbage collection is implemented in DWS through reference-counting (based on Delphi’s interfaces), and supplemented by a special garbage collector which is responsible for handling and cleaning up object dependency cycles.

If you have no particular memory constraints or requirements, you can thus safely create objects in DWS and not worry about their release. The special cycles GC means DWS isn’t vulnerable like Delphi’s interfaces-based reference-counting is.

Manual destruction of objects

With DWS 2.2, destructors are being brought back in a meaningful way, i.e you can manually destroy an object that is still referenced, and the object will then acquire a special “destroyed” status. Any attempt to access a destroyed object’s fields, or invoke a destroyed object’s methods will trigger an exception.

Beyond controlled release, this mechanism can be used to make sure that an object, even if incorrectly kept around, can’t be used anymore without an exception happening.

Note that unlike in Delphi, to guarantee the correctness of the “destroyed” status, a destroyed object that is still referenced will still use some memory, for as long as it is referenced. However, that object’s Delphi-side objects and memory can have been freed, as well as the object’s memory used to store the object’s fields.

When debugging, it is possible to iterate over all script objects (via the program’s execution object), including all the “destroyed” objects which are being kept because of “dangling” references.

Cleanup of “leaked” objects

Objects that have not been manually destroyed, and are still referenced by the time EndProgram is executed will be cleaned up without having their destructor invoked. This covers the cases where the script execution has been completed (end of code reached), has been aborted Delphi-side, via an execution timeout, or terminated because of an unhandled exception.

The destructors are not invoked because when EndProgram is triggered, the script is no longer supposed to be running in a any way or form: the stack has been torn-down, and cross-object references become meaningless as the clean up forcibly proceeds.

For external objects exposed through TdwsUnit, you will get an OnCleanup event, which allows you to release your Delphi-side objects, though in OnCleanup you have to be aware that the script has already been terminated, so you shouldn’t Call script functions, or rely on other script objects still existing or being valid.

DWScript: Class const, more hints, RTTI…

Recent additions to the SVN for Delphi Web Script:

  • class constants are now supported.
  • compiler will now warn about simple cases of unreachable code.
  • new hints available when coSymbolDictionary compile option is set:
    • compiler will hint about declared, but unused variables.
    • compiler will hint about unused Result pseudo-variable.
  • SymbolsLib brought over from DWSII repository and updated, it provides RTTI functionality from within the scripts.
  • various fixes and extensions to the unit tests suite

Temporary lull

Website will be in a temporary lull as I’m now involved almost full-time in a brand new offline project of the milk-drinking variety, codename “Lucie” 😉

Spotlight on TdwsSymbolDictionary

A useful, yet not very prominent class of DWScript is TdwsSymbolDictionary. It provides a reference of  all symbols mentioned in your script, where they are declared, where they are used, etc. It is optionally filled up when you compile a script with the coSymbolDictionary compile option, and can be accessed from a compiler program object or interface.

It can be used for multiple purposes, centered around IDE features and auditing. Here are a few usage scenarios.

In-place symbol help and navigation

The most basic use of TdwsSymbolDictionary is probably to figure out which symbol is under the cursor or the mouse in your code editor. You can then use the symbol to provide relevant contextual help (either from your help file, or auto-generated from the script, such as a list of parameters for a function, of fields for a class, etc.) or look up the dictionary once more, and provide information about where it’s declared, implemented, used or forwarded. That positional information can also be used to offer navigation shortcuts between declaration and implementation, or to any of the symbol’s occurrences in the source.

Auto-completion

The TSymbolDictionary can be used it to figure out what is currently being typed, by identifying the symbol at the cursor, or the last recognized symbol in the code being entered. From that point on, you can generate a list of contextual variables, methods, fields, etc. that can be used to fill up an auto-completion drop down.

Code Refactoring

Once you have a symbol pinpointed, either by name or through one of its occurrences in the source, you have access to all the places it’s occurring in the code. A trivial use of such a list is for a rename refactoring: as the list of symbol positions is already sorted by source file, line and column, you merely have to walk the list backwards and replace occurrences in your sources files.

You can also team up TdwsSymbolDictionary with  other information sources to implement more complex refactorings. For instance alongside TdwsSourceContextMap (which is also provided in a compiled program), you can implement “extract method” (or its variants, “pull up” & “push down”).

Code Auditing

The symbol dictionary can be a convenient starting place for symbol-related audits and diagnostics. All audits that relate to the amount of times a symbol is used (or not) being the most trivial.

Another straightforward usage is when you have naming conventions for fields, variables, classes etc. and/or to enforce case consistency. The later can be handled in your IDE in a similar fashion as a rename refactoring, except you only replace in suReference and suImplementation symbol positions, and it is harmless enough you can do it in a background task without requiring user interaction.

You can also use it to diagnose code issues, for instance such patterns:

someObject.someProperty[stuff].otherProperty.function.method(1);
someObject.someProperty[stuff].otherProperty.function.method(2);
someObject.someProperty[stuff].otherProperty.function.method(3);

can be heuristically detected (either as “too many member symbols on the same line” or “member symbol repeated too much in nearby lines”), and the attention brought to the hot-spots so the code can be simplified and cleaned up.

DWScript news: classes, exceptions, speedups

There have been quite a few changes, fixes and enhancements to DelphiWebScript, available in the SVN version:
  • class visibility is now enforced: private and protected are equivalent to Delphi’s strict private and strict protected. Other levels are public (members accessible to the whole script) and published (default visibility, to be used for external exposure, RPC, persistence, etc.)
  • added support for class abstract and class sealed: an abstract class has to be subclassed before it can be instantiated, a sealed class can’t be subclassed.
  • virtual methods are now based on a Virtual-Method Table, previously they were implemented in a way vaguely similar to Delphi’s “dynamic” methods. The new implementation is much faster, but at the cost of a (hopefully reasonable) memory overhead.  VMTs are shared, and thus only use memory for classes that actually introduce or override a virtual method.
  • fixes and improvements to the exception handling (ExceptObject now available).
  • fixes to the circular reference garbage collector.
  • fixes and improvements to the virtual class methods support, and properties based on class methods.
  • class-less procedures and functions calls are now faster.
  • partial inlining loop unrolling optimization for small statement blocks*.
  • other misc. optimizations, improvements and fixes.

There is also a new JSON support unit, which isn’t currently used by DWS, but has been introduced for testing and investigations. The strict JSON parser is AFAICT about twice faster than the current “fastest” Delphi JSON parser, with still some room for improvements.

*: the impact of those seem to be highly CPU-dependent, f.i. on the “Mandelbrot” demo, the speedup is a few percentage points on an AMD Phenom, but about 40% on my Intel Core i5.

edit: to be more accurate, it brings the Intel processor up to the level of the AMD cpu, the code must have been hitting a weakness in the Core i5 branch predictor.

SamplingProfiler 1.7.7 released

Version 1.7.7 of Sampling Profiler has been released, you can grab it here (642 kB), this version fixes the following issues:

  • Fixed gathering of samples in Monte-Carlo multi-threading mode.
  • Fixed crash when closing a results page with Ctrl+F4.
  • No longer restores to maximized or minimized state.

Leaps and bounds of DWScript

A DWS 2.2 preview zip (199 kB) has been posted, it is an SVN snapshot, and features recent additions to DWS:

  • Contracts are now partially supported: ensure, require and old are available and use the same syntax as Prism contracts, inheritance is supported, class invariants are not in just yet, mostly for syntax indecision reasons, see this thread.
  • the implies operator is now supported, “a implies b” is equivalent to “(not a) or b”, or in other words, it is false only if a is true and b is false.
  • Assert() is supported, and will trigger EAssertionFailed in case of, well, an assertion failure. A compiler option has been added to control the generation of assertions.
  • Exception now has a StackTrace method, which will return a textual stacktrace script-side. Runtime errors now also include a stack trace, and new Delphi-side methods provide access to even more details.
  • the in operator has been extended to allow class overloading, f.i. you can now use “if (aString in someStringList) then…”, the not in form is also supported.

A fair chunk of the error and exception code has been refactored, if you were relying on it, all the preexisting functionality is still there, though it has been shuffled around to (hopefully) more relevant locations.