SC, Rev,and RB speed test

[David Vaughan]

On 15/04/2004, at 17:51, Chris Yavelow <Chris at yav.com> wrote:
>
>
> I'm conducting an informal speed test comparing identical projects in 
> SuperCard (4.1.2), Revolution (2.2), and RealBasic (5.5.1). The 
> projects match 3,000 short phrases against an 81,920 word text. There 
> has already been some feedback and these simple projects are now 
> running even faster. Each one is only a dozen lines of code.
>
> Here are the current statistics:
>
> RealBasic -- 234 ticks
> Revolution -- 1120 ticks - [1548 ticks or nearly 26 seconds on my 1GHz 
> G4 Powerbook - DV]
> SuperCard -- 1889 ticks
>
> I've set up a page for downloading the sample projects, if you'd like 
> to try to tweak them to run faster. The object is not the fewest lines 
> of code, it is to create the fastest code (without xfcns or xcmds, 
> etc.). You can inspect the latest version of the code there as well, 
> and see the latest speed results (in ticks).

I had another look at the test stack from Chris. His text to be 
searched (target text) comprises 8192 identical 42-character lines and 
his search text comprises 2900 identical 15-character lines and another 
100 identical 10-character lines which match the target text. So, the 
array method put forward by Ken Ray and improved by Geoff Canyon 
resolves to searching a one line variable for either of two other 
lines. I am not surprised it is fast (37 mS on my machine).

I created a string containing the sets 0-9, a-z and space and then 
generated text of 8192 lines each of 42 characters selected by randomly 
accessing that string 42 times. The search text was similarly created 
with 3000 lines of fifteen random characters each. There were no 
matches, and the array approach was of course slower than the original 
method, although not by a lot so it remains very relevant wherever a 
bit of replication is expected.

I think Richard Gaskin's query is pertinent. The question is very close 
to "find the intersection of two large sets". Is that the crux of the 
real life problem? Are there any other considerations? With more 
information about the real data I believe that we could improve the Rev 
performance in other ways so that it suffered no user-recognisable 
performance handicap in the real world.

regards
David