RunRev vs RealBasic
Frank D. Engel, Jr.
fde101 at fjrhome.net
Mon Jan 3 10:22:35 EST 2005
-----BEGIN PGP SIGNED MESSAGE-----
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
>> 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
> 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
> 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...
> Chipp Walters, Altuit.com
> Sent from my Sidekick
> use-revolution mailing list
> use-revolution at lists.runrev.com
Frank D. Engel, Jr. <fde101 at fjrhome.net>
$ 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)
-----END PGP SIGNATURE-----
$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 www.doteasy.com
More information about the Use-livecode