Rev now tied with RB at 78 ticks

Richard Gaskin ambassador at
Wed Apr 21 23:45:39 EDT 2004

Chris Yavelow wrote:
> Richard Gaskin wrote
>> the obvious choices for that task, C
>> or Assembler, remain ommitted from the evaluation.
> I don't see C or Assembler as the "obvious choice" -- Although I have 
> taken courses in both, I don't know enough about either to make the 
> development time-effective. Can C really open a 120,000-word file and 
> another file, and then compare them for matches, and then display the 
> results in significantly less than 78 ticks?

I thought we'd moved past significant speed differences quite some time 
ago. ;)

But seriously, what do you think Revolution, RealBASIC, and SuperCard 
were written in?

Rev and SC are flexible enough to have their IDEs written in their own 
scripting language, but the core engines for all three are based in C. 
Most operating systems are written in C, as are most device drivers and 
of course most commercial applications.  OS vendors document their APIs 
with C interfaces, there are millions of lines of efficient code 
examples for them, and most C compilers offer a wide range of 
optimization options.

So yes, I would imagine that less generalized code written in C to 
address the specific task would be much faster than running it through 
the Rev VM or the BASIC libraries first.

But all of this raises some questions about "compiled" languages:

If one compiles to true machine code, the language used should not play 
a significant role in execution speed; machine instructions are machine 
instructions.  Tom Pittman used to argue that while Pascal was easier to 
write than the Assembler-substitute that is C, with appropriate compiler 
optimizations the object code should execute at least as fast (actually, 
he felt Pascal was more compilation-friendly and should therefore run 
measurably faster, but that's a different story).

In contrast to ostensibly "compiled" languages, Rev makes no bones about 
its two-pass on-the-fly compilation.  The traditional argument in favor 
of 4GLs centers instead around productivity and overall ROI, and since 
most of what's executing in a 4GL is indeed highly-optimized C in the 
VM, a good modern 4GL like Rev will likely perform adequately for most 

But since 4GLs are typically made with a 3GL, no one expects a 4GL to be 
as fast as a 3GL.

Yet in this case it is.

So for all the DIM statements, the bit-counting, data typing, 
compile-runtime cycles, inability to modify code at runtime, generally 
longer blocks of code, translating OS API examples from C to Beginner's 
Code, etc., the merely semi-compiled Rev is still as fast as an 
ostensibly "fully compiled" language.


In my office when speed is critical the answer is C, and when ROI is 
critical the answer is scripting.  Rev gives us the option to use either 
as needed.  I spend _much_ more time on user task analysis than on 
coding, but that's not a luxury lower-level languages afford for 
vertical products, at least not at the same level of profitability.

And as this exercise has illustrated, with Rev it's pretty rare that 
speed is critical enough to require C.

For another fine example of good Transcript in action, check out 
MindLube's RevCLIPS library at 
<>.  It's a native Transcript 
implementation of the CLIPS expert system -- Alex has effectively used a 
4GL to write a 5GL, with very impressive results.

> [snip]
>> But as of this morning this doesn't matter:  Thanks to Brian Yennie's
>> post, Rev either retook the lead or is so close the differences are
>> negligible (depends how the testing will turn out on Yav's machine).
>> Here's the post in case you missed it:
>> ---------------------------------------------------
>> On guard! Another Rev entry!
> Yes, Brian Yennie's contribution evened out the playing field. RB and 
> Rev are now both at 78 ticks. Bravo!
> Chris

Now that the speed of this one function is out of the way, what other 
criteria will you be evaluating for the project at hand?

  Richard Gaskin
  Fourth World Media Corporation
  Ambassador at

More information about the Use-livecode mailing list