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
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution



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


-- Richard Gaskin Fourth World Media Corporation ___________________________________________________________ [EMAIL PROTECTED] http://www.FourthWorld.com _______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution

Reply via email to