[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