REV, RB, SC speed test, Latest results

David Vaughan dvk at dvkconsult.com.au
Tue Apr 20 21:24:13 EDT 2004


On 21/04/2004, at 1:02, Norman Winn <norman at mrsystems.co.uk> wrote:

Norman

I am aware of responses already from Ken Ray and James Richards to your 
comments below but, as author of the key programming step I find excuse 
to add my own perspective.

> I am a user assessing Revolution as a replacement++ for Filemaker. I 
> am also assessing other tools so am following this discussion with 
> interest. Here are my observations:
There has been a recent thread on Filemaker and RR. If you missed it 
you should look it up as well.
>
> 1)  Can any of you consider this to be a fair comparison?
Yes. Perfectly. It was up there on the web site for the same time for 
everyone and, so far as I know, posted to all the lists. I assume that 
the RB players paid it no attention as the game appeared already won. 
In any case it took me very little time after I got hold of real data 
to work out a solution and another day before I had time to publish. As 
I have written previously I think winning "it", the simple speed 
comparison, does not matter.
> You, the 'you' being probably the best RR programmers on the planet, 
> have had a couple of weeks [sic] to optimise RR's algorithm.
Sorry, because there is no reason you would know, but this is 
hilarious; at least for me, not for my brilliant colleagues. I have not 
programmed anything for sale or direct profit since selling my small 
business at the end of the eighties. For me, RR is a handy scripting 
tool replacing awk for one-off manipulations of patterned data and 
HyperCard for small applications which help me either in my business or 
my hobbies. I know practically nothing of its multimedia or visual 
design capabilities, for example, and never read those posts.
>  Has the sense of justice in anyone pushed them to pass the challenge 
> to the RB list?
You know now that Ken said as much. You might also look up my response 
to his post to see that in my view all of this is fairly unimportant 
anyway. See also Richard Gaskin's posts on the topic.
>
> 2) One of the suggested strengths of Revolution is the simplicity of 
> getting things done. Why should such a common task take such a lot of 
> optimisation to produce the best results? Are not the 'out of the box' 
> solutions i.e. those that will be produced by the average user, a 
> fairer comparison?
As Ken pointed out, the challenge was not "What does it do?" but "This 
is what it does; make it go faster". The actual text from Chris' first 
post is "...try to tweak them to run faster. The object is ... to 
create the fastest code..."
>
> 3) On a more positive note, the possibilities of optimisation have 
> revealed to me a rich programming environment underlying the IDE,
Now we come to the important point, at least to me. The original 
problem set by Chris used artificial data. Ken Ray promptly blew that 
away by exploiting the enormous redundancy using a keys comparison. I 
wrote to Chris asking for some real test data and at about the same 
time he put some up on his site. Seeing data patterns, I exploited this 
and an alternate Rev command to more or less settle the issue. Chris 
tried some tests on real real data and before and after this Monte 
Goulding and Brian Yennie published what I call production 
optimisations, which exploited possible repetitions in serial analyses.

Note the thread in this: optimisation is a function of the data you 
face, more than the tools at hand. Richness of the tool set makes more 
optimisation opportunities available. Here, we optimised speed. 
Remember those other two in the impossible triangle, cost and 
quality?**  They too can be optimised with Rev, which is partly why I 
enjoy using it.

Hope you make a sound product choice which satisfies your application 
needs, is enjoyable _for you_ to work with and is well supported on its 
user list.

regards
David

**(Old programming/engineering saying: You want it fast, high quality 
and cheap; any one is easy, you can get two, but you can never have all 
three)
>
>
> Norman Winn


More information about the use-livecode mailing list