But what's the question?

[Richard Gaskin]

Norman Winn wrote:

> Monte Goulding wrote:
> 
>> We can't change the fact that RB has a faster substring
>> searcher than Rev
> 
> I am glad this comment has appeared. Not that I want to judge the tool I 
> use on a single test but because I felt doubts of being part of 
> something where those deeply involved didn't come up out with clear 
> statements like this.

I don't think anyone here was claiming that Rev outperforms all other 
tools in all tasks.

But by the same token, if the ostensible reason for the comparison holds 
up we can look forward to a great many other relevant measurements 
appearing on that page as the evaluation for the project at hand continues.

Any evaluation of tools that focuses solely on one task will likely 
yield suboptimal results, esp. if the obvious choices for that task, C 
or Assembler, remain ommitted from the evaluation.

> Sarah Reichelt wrote:
> 
>> In a real world application, who cares whether a particular
>> routine takes 100 ms or 500 ms
>
> If you are contemplating building big, complex solutions this does 
> matter. Sure, when you start out you don't notice the difference. As 
> time goes on and routines call others that call others .... these time 
> differences multiply.

Indeed, but in practical terms it depends on the specifics of the app. 
Just how big is the difference, and how frequently is the function 
called?  There is ultimately a point of diminishing returns for most 
optimization efforts.

And of course when speed is really critical, as long as 3GLs are an 
option chances are you'd get much better results using the industry 
standard 3GL, C.  You can do that in an external and still get the 
productivity benefits of a 4GL for the other 90% of the development cycle.

But as of this morning this doesn't matter:  Thanks to Brian Yennie's 
post, Rev either retook the lead or is so close the differences are 
negligible (depends how the testing will turn out on Yav's machine).

Here's the post in case you missed it:

---------------------------------------------------
On guard! Another Rev entry!

Notes:

1) I went back to building the mini-index of first letter hints from 
words, and caching the index for future searches
2) I took advantage of the caseSensitive property, which noticeably 
speeds up offset()
2a) I noted that the position in the full text has to be at least 2x-1 
that of the 1 character index
3) I used a quick array to keep track of two-word combos and quickly 
eliminate any line which has a non-existent one in it
4) I used lock/unlock screen because the screen was previously being 
updated 6 times instead of once (once for each put into a field, 
including the timing mechanism).

My benchmarks are:

HARDWARE: iBook 500Mhz - has been benching at pretty close to 50% speed 
of Chris' test machine
FIRST RUN (which creates cached index): 130-135 ticks
ADDITIONAL RUNS (with cached index): 58-62 ticks

Cut those in half, and we would have 65-68 ticks on the first round and 
29-31 on each additional, which would actually be faster than the RB bench!

Of course only Chris can tell us how they run on his end =).


##########

local shortFindList, isWord, textDigest, tTime

on mouseUp
   local tMatchList, sMS, fn, stList, shortFind, w, w0, c

   ## if you want to force refresh of index
   if (the optionKey is "down") then put empty into textDigest

   set cursor to watch

   put the milliseconds into sMS

   lock screen
   put empty into tTime

   ## use URL syntax for faster file loading
   put "./TargetText.txt" into fn
   put url ("file:"&fn) into tMatchList

   put "./SearchTextList.txt" into fn
   put url ("file:"&fn) into stList

   put timeit(sMS,"Load Data") into sMS
   -- stripping quotes from both sets saves problems with single quotes
   --  or with quoted strings being treated as a word

   replace quote with empty in stList
   put lower(tMatchList) into tLowerMatchList
   replace quote with empty in tLowerMatchList

   put md5Digest(tMatchList) into tDigest
   if (tDigest <> textDigest) then
     put empty into shortFindList
     repeat for each word w in tLowerMatchList
       put char 1 of w into c
       put c after shortFindList
       put TRUE into isWord[w]
       put TRUE into isWord[w0&w]
       put w into w0
     end repeat
     put tDigest into textDigest
   end if

   set the caseSensitive to TRUE

   repeat for each line inLine in stList
     put empty into shortFind
     put lower(inLine) into inLineLower
     put 0 into i
     put empty into w0
     repeat for each word w in inLineLower
       if not isWord[w0&w] then
         put empty into shortFind
         exit repeat
       end if
       put char 1 of w after shortFind
       put w into w0
     end repeat
     if (shortFind is empty) then next repeat
     put offset(shortFind, shortFindList) into x
     if (x > 0) then
       if (offset(inLineLower, tLowerMatchList, x*2-1) > 0) then
         put inLine & return after MatchList
       end if
     end if
   end repeat
   put timeit(sMS, "Check Matches") into sMS
   put MatchList into fld "TheResults"
   put stList into fld "SearchTextList"
   put tMatchList into fld "TargetText"
   put timeit(sMS,"Display All") into sMS
   put tTime&cr after fld "SpeedRecords"
   unlock screen
end mouseUp

_______________________________________________
use-revolution mailing list
use-revolution at lists.runrev.com
http://lists.runrev.com/mailman/listinfo/use-revolution



--------------------------------------------


-- 
  Richard Gaskin
  Fourth World Media Corporation
  ___________________________________________________________
  Ambassador at FourthWorld.com       http://www.FourthWorld.com