But what's the question? (was: RB clear winner in speed test)

David Vaughan dvk at dvkconsult.com.au
Tue Apr 20 23:16:12 EDT 2004


On 21/04/2004, at 10:45, Chris Yavelow <Chris at yav.com> wrote:

> Now there has been considerable activity on the RB list, and the total 
> speed is down to 77 ticks for RB, 70 for Revolution. But, looking at 
> the Revolution code, I see that the hacks are optimized for 3-word 
> searches, and that's not the intention. Also, RB counts all the 
> duplicate matches (for a total of 248) while Rev doesn't count the 
> dupes and comes to 192 matches.

and later

> Thanks for the help in working this out. The people from the 
> Revolution list had gradually optimized the code for 3-word strings. I 
> have generated new search data consisting of random lengths from 3 to 
> 7 words and the effect on the Revolution speed is staggering, while 
> there is no effect on the RB speed.

Chris, what are you doing?
Several points come immediately to mind:
- There are no hacks
- The Rev code was not "gradually optimised for 3-word strings". It was 
directly optimised for each successive data set you published; nothing 
gradual about it.
- Why are you staggered by the effect on the Rev speed? If you read any 
of the previous posts (e.g. from Dar Scott) then you and we already 
knew instrb() was much faster than "is in", and we have changed none of 
that.
- Do you want dupes counted twice or not?
- How many words do you wish to search for (you published 1-27 with a 
mode of 3 then said 4-7 but published 1-7 with a mode of 7)
- Are searches repeated for either source or target text?
- Your web site has for a couple of days published as the Rev code a 
mix of lines from RB and Rev i.e. rubbish.
- Your data is wrong or else a tick lasts 42mS under RB but the usual 
~17mS under Rev
- Your web site promised to credit improvers (but please do not 
associate my name with it) but you have not fulfilled that promise for 
anyone at any time.

Incidentally, I immediately cut your published Rev time to 2 seconds 
but I decline to publish for three reasons:
- It should be obvious to you anyway, if you think in concepts or 
strategies and not hacks
- I do not trust you have stated the problem completely - i.e. your 
real-world application
- I no longer trust that you are comparing products in any broad sense 
(see my previously published comments in response to Ken Ray and to 
Norman Winn for consistency of my position).

regards
David



More information about the use-livecode mailing list