SC, Rev,and RB speed test
dvk at dvkconsult.com.au
Thu Apr 15 22:22:09 CDT 2004
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.
More information about the use-livecode