RunRev vs RealBasic

Frank D. Engel, Jr. fde101 at
Mon Jan 3 10:22:35 EST 2005

Hash: SHA1

On Dec 31, 2004, at 5:04 PM, Chipp Walters wrote:

> On Fri, 31 Dec 2004 2:40 pm, Ken Ray wrote:
>> That's one of the beauties of Rev... data can be stored *inside* the 
>> stack
>> files, either as data in fields that have been saved, or as custom
>> properties that are stored with the stack itself.
> A great point. I recently was able to create a compressed, encrypted 
> binary data storage file using a stack and a single line of code. This 
> data file stores text data along with imades in 3 different formats.
> This data file is actually a stack with no business logic and is 
> opened by my app invisibly and data selectively moved to the gui, 
> edited there and then moved back to the inv stack to save. Talk about 
> simple. Doing the same in VB would be very complicated. I imagine RB 
> too.
> Btw, regarding speed issues, I think there have been a number of speed 
> coding challenges between RB and RR with no conclusive winner. Perhaps 
> Frank can be more specific with regard to areas he feels RR runs slow?

Again, CPU-Intensive routines, such as processing each byte of a long 
string individually.  Most of the more "stock" operations run quite 
well in Rev, but when doing intensive, custom CPU-intensive routines, 
it generally pays to write an external, particularly when targeting 
older hardware.

> Also, last time I looked, RR compiles scripts 'on the fly' like Java. 
> Didn't know RB was a compiler. Must be tough on edit/compile/run/debug 
> cycles. Perhaps it's an interpreter like RR and compiles during 
> runtime? I don't know.

Rev "compiles" scripts into a bytecode format which is later 
interpreted by the runtime environment.  Faster than a "pure" 
interpreter, but still slower than compiled code.

Java code gets run through a compiler which translates it into a Java 
bytecode.  That bytecode is then interpreted at runtime, much as is Rev 
code.  However, some Java runtime environments (JREs) will actually 
"recompile" the bytecode into native code for the platform.  This is 
slower than compiling code directly for the hardware, but adds the 
write-one-run-anywhere flexibility of Java (and to some degree of Rev), 
and the result of this (sometimes referred to as "Just-In-Time" 
compilation) is much closer in speed to native compiled code.

Real Basic is a true compiler, which translates code into instructions 
for the actual hardware on which it is run.  This is the fastest 
solution, since the computer hardware does virtually *all* of the work 
of figuring out how to execute each instruction, and there is no 
runtime translation step.  However, this also locks the compiled 
version to the platform for which it was compiled (similarly to a 
standalone produced by Rev), and it causes a Compile-Run-Debug cycle to 
be introduced.  Visual Basic (M$ product) is also a true compiler.

I personally wonder what it would take to create a true compiler for 
Rev stacks?  Obviously this would introduce some limitations on certain 
operations, but for stacks which don't use those operations, it could 
substantially increase performance...

> Best,
> Chipp
> Chipp Walters,
> Sent from my Sidekick
> _______________________________________________
> use-revolution mailing list
> use-revolution at
- -----------------------------------------------------------
Frank D. Engel, Jr.  <fde101 at>

$ ln -s /usr/share/kjvbible /usr/manual
$ true | cat /usr/manual | grep "John 3:16"
John 3:16 For God so loved the world, that he gave his only begotten 
Son, that whosoever believeth in him should not perish, but have 
everlasting life.
Version: GnuPG v1.2.4 (Darwin)


$0 Web Hosting with up to 120MB web space, 1000 MB Transfer
10 Personalized POP and Web E-mail Accounts, and much more.
Signup at

More information about the Use-livecode mailing list