RunRev vs RealBasic (Richard Gaskin)

[David Grogono]

Chipp Walters wrote:

> In fairness to Rev, there was no stipulation regarding how many lines of
> code it take to generate the results. In fact, one could concatenate all
> lines of the Rev code using ';' to solve the problem in only 1 line of
> code ;-)

True, there wasn't a line requirement.  However, since the speed was roughly
the same in both cases I'd be much happier maintaining the 6 lines of code.
I have a hard time believing that most people can look at this particular
Rev code and easily understand what it's doing.

> Also, there are certainly different things going on in the two code
> snippets you posted. In RB, variables are not declared, but in Rev some
> are instantiated-- not to mention the MD5digest reset switch (only in
> the Rev code).

Valid point, although the amount and readability of code would still be
quite different.

> Also, as I recall, this project was a 'moving target.'
> Once Rev posted a 'winning time', the challenge changed benefiting RB.

Not true.  At first no-one on the REALbasic list spent any time optimizing
the code since the initial post had found REALbasic to be 5 times faster.
Once there was some Rev code that appeared to be faster, those on the
REALbasic list took up the challenge.  During this process someone noticed
that the new Rev code was inadvertently ignoring duplicate matches.  Rev may
have been faster at this point but the code wasn't doing the full job.  It
was also pointed out that the Rev code had been optimized for 2 and 3 letter
searches and the original poster decided to update his data set to be more
representative of his needs.
 
> Assuming 'readability' and 'maintainability' were set as primary goals,
> it's hard to deny Xtalk languages excel in both areas.

Sure, but in order to get maximum performance in this particular case it
seems both of these things have been sacrificed.
 
> All that said, it does look like either application can handle string
> parsing w/out problems.

Agreed.
 

Richard Gaskin wrote:
 
>> A number of small clarifications on this.  The person who started
>> the speed comparison was not an "RB fan" but rather a SuperCard
>> user evaluating both REALbasic and Revolution.
> 
> Having once been the leading vendor of third-party components for
> SuperCard, I've known him for more than a decade.  Somewhere in the
> communications he mentioned that he'd felt so burned by the Allegiant
> experience that he was resistent to working with xTalks in general, and
> accordingly had a preference for RB.

He didn't have a preference for REALbasic, in fact very early during the
thread he mentioned that he was a REALbasic novice:

>>> You know more than most on this list that I will squeeze every
>>> millisecond out of my code, but SuperCard will only go just so fast.
>>> I'm just a novice with Revolotion and RealBasic, so I'm trying to
>>> figure out if RealBasic really is THAT fast and whether Revolution
>>> can't be coaxed to go a bit faster than I'm able to make it.

>> His initial attempt found that REALbasic was significantly faster than
>> Revolution.
> 
> That was the second round.  The first round had Rev way in the lead
> (twice as fast IIRC), using nothing more than a half-dozen lines of code
> found in an old MetaCard example stack.

I can't find any evidence of this assertion on either mailing list.  The
above quote seems to indicate he had found otherwise.

>> After both sets of code were further optimized the speed differences
>> were negligible.  The primary difference after optimization is the
>> readability and maintainability of the code.  The guts of the routine
>> in REALbasic is 6 lines of code but 37 lines of code in Revolution.
> 
> We could selectively compare subsets, but to get the job done the final
> published code listings have 74 lines for RB and 79 lines for Rev.

True, but the RB code will display appropriate error messages when the data
file is missing or locked.  It doesn't look like the Revolution code does
this.  Removing this code could save 20+ lines.  Alternatively the same
functionality could be accomplished with fewer lines if anyone cared.

>> As for the speed of the load, the results are probably misleading
>> for REALbasic because it includes the first step of string processing.
> 
> It's odd that after so many RB'ers helped with that code they came up
> with an inefficient method.

I never said the method was inefficient.  I was just pointing out that the
timing wasn't simply timing a file load.  You were using this one data point
to imply that Revolution loaded files twice as fast as REALbasic.
 
> But maybe it's not so bad -- his Rev code uses:
> 
>   put url ("file:"&fn) into tMatchList
> 
> That also does string processing, changing any line endings to match the
> Unix convention used internally within the engine.  "binfile" is often
> faster than "file", since it loads the file wholesale without modifying
> line endings.

This demonstrates my point.  The definition of "load" was peculiar to this
example and shouldn't be used as a basis for a general comparison.

>> Either way the load is extremely fast in both environments and
>> it's a tiny tiny fraction of the total task.  Here's the code for each
>> environment:  copied from <http://www.yav.com/speed.html>
> 
> From that page:
> 
>                RealBasic (5.5.1)   Revolution (2.2)
> 
> Load Data           28 ms                   14 ms
> 
> Check Matches     1036 ms                 1049 ms
> 
> Display All        184 ms                  188 ms
> 
> TOTAL            1248 ms (78 ticks)       1251 ms (78 ticks)
> 
> 
> What's interesting here is not RB vs. Rev, but RB vs. C.  One of the
> advantages RB personnel like to tout is that RB is "fully compiled", in
> contrast to what they characterize as Rev being "interpreted" (in truth
> Rev is a bit of both, like Java but with more efficient structure, but
> that's another hair-splitting story).
> 
> If RB were indeed "fully compiled", we should expect it to beat the
> pants off of any "interpreted" language by a very wide margin, and have
> speeds more in line with what one would expect from compiling C or
> anything else that outputs machine-specific object code.

REALbasic is indeed fully compiled.  In any language it is possible to write
inefficient code.  I wouldn't be at all surprised if someone's first attempt
in C would be much slower than the times you quote above.
 
> That so many common tasks perform with nearly equivalent speed in an
> ultra-high-level language like Transcript speaks rather well for its
> inventor.
> And given the many productivity advantages to typeless
> languages outlined by Osterhout and others
> (<http://www.tcl.tk/doc/scripting.html>), Rev makes a very strong case
> for itself that more than compensates for the few specialized cases
> where RB may actually turn out to be significantly faster.

I'm glad you're happy with your development environment.

Best regards,
David Grogono