[OT] RE: counter++ versus

Dar Scott dsc at swcp.com
Thu Mar 25 12:50:10 EST 2004


On Thursday, March 25, 2004, at 09:09 AM, Kevin wrote:

> If you ask me 'RR' is much slower than I would have expected a engine 
> of its maturity and evolution.  Forth interpreters using direct 
> threading and even token threading are considerably faster than 'RR'.

That is how I would do it (being ignorant of the experiences of xTalk 
developers).

As mentioned in the discussion on when compiling is done, there are 
tradeoffs between the two threading methods.

There are some things to consider in comparing speed.  Revolution uses 
values that might be arrays or strings and the strings might really be 
floating point numbers.  Forth interpreters typically uses words.  
However, Revolution seems to handle values pretty fast in built-in 
code.  Also, the Transcript is more complicated than it looks.  An 
example is an object reference.  In this case, probably more can be 
done at the compiler level.  Transcript supplies some script 
information in errors; the selected method might have a speed impact.

The last time I was timing Revolution constructs, the release I was 
using turned out to be a debug build or something and ran slowly.

> There are also several constructs that can drastically alter 
> performance in a TIL.  For example many TILs use a hash table for 
> their dictionary.  In a large implementation these can cause 
> significant speed anomalies.  In many of the engines I built the 
> dictionary was a Red Black Tree to ensured optimal performance (more 
> information it available on this data structure can be found int 
> Robert Sedgewick's Algorithms book).

The independence of objects and the semantics of calls requires a 
search through the message path, presumably through a sequence of 
optimized tables.

Some methods for optimizing this have been discussed on the "improve" 
list.

One dynamically makes the link direct between times of possible changes 
in scripts and paths and related changes.  This requires no language 
change.

Another adds the concept of a script local function or command.  This 
hides the name from other scripts and requires references to it in the 
script to skip the message path and use the local function or command.  
I would expect the compiler to compile a direct call in this case.  
This is a small language change.


As far as only 7 times slower...  Well, I have sometimes said that 
arithmetic in Revolution is much too fast.  As far as the number?  
Well, I spent the first few years of my life in Missouri.

Dar Scott



More information about the use-livecode mailing list