REPLACE ANY vs. just REPLACE

[Gösta H. Lovgren-2]

Reason for speed difference?

From TM: (and what MCM actually said)

Syntax REPLACE [ANY] MatchString WITH NewString IN MainString

Remarks The REPLACE statement replaces all occurrences of MatchString in MainString with NewString. The replacement can cause MainString to grow or shrink in size. MainString must be a string variable; MatchString and NewString may be string expressions. REPLACE is case-sensitive.

ANY If you use the ANY option, within MainString, each occurrence of each character in MatchString will be replaced with the corresponding character in NewString. In this case, MatchString and NewString must be the same length, because there is a one-to-one correspondence between their characters.

=============================
To be, or not to be: that is the question:
Whether 'tis nobler in the mind to suffer
The slings and arrows of outrageous fortune,
Or to take arms against a sea of troubles ...
William Shakespeare (1546-1616)
=============================

[Michael Mattias]

>Still function calls though

Where?

PEEK(LONG, STRPTR(S) + iOffset)
is the same as

LOCAL pL AS LONG PTR
 pl = STRPTR(S) + iOffset
 IF @pl =  targetLongval THEN

The compiler is doing all the stuff you DON'T type. (That's why it's called a high-level language)

Still ain't got no string manipulation functions (the time-consuming stuff).

MCM

[Roger Garstang]

Still function calls though...and while probably not much difference it still isn't as simple as just a =, <, >, <> compare or ++, --, +, - modifiers, etc.

[Michael Mattias]

. I wish PB allowed Byte/Char Compares like C/C++ without needing Pointers or other coding methods.

Um, it does support byte comparisions against strings. See ASC() function in help file.

And I 'suppose' you could do INTEGER and/or LONG compares within a string with something like...

 iIOffset       = something     ' offset of starting byte within string for long compare
 IF PEEK(LONG, STRPTR(Stringvar) + iOffset) = targetlongvalue& THEN 
  ....

No MID$, LEFT$/RIGHT$ or concatenations in that code.

[Roger Garstang]

Yes, that makes sense. I was thinking too deep. I wish PB allowed Byte/Char Compares like C/C++ without needing Pointers or other coding methods. Numeric compares are much faster. I often use LEN() = 0 Compares instead of comparing to "", etc for this very reason.

[John Gleason]

>> code which must allow for variable-length targets.

I too think that's got to be the major factor. The ANY version gets in a quick short replacement loop that the non-ANY version takes a longer way around.

I thought this ANY addition might be an interesting point because a person could reasonably think, "Hey, I want my code compact and as efficient as possible and therefore don't want to put a redundant ANY in there and gum it up." But in this case, that seeming redundancy is actually quite an improvement.

[Michael Mattias]

Best guess: since "ANY" does ONLY single-character replacements (vs. REPLACE 'not any'), the compiler can generate code similar to my example, which compares numbers versus comparing strings, with numbers is always faster.

That is, without ANY the compiler has to generate code which must allow for variable-length targets... which surely takes longer to execute than does looking only for fixed-length (one character) targets.

MCM

[Roger Garstang]

Interesting, does ANY spawn threads or something usually to speed up and search for all the ANY values at once causing this speed up?

[Michael Mattias]

If you are restricted to BYTES it might be even faster to ..

FUNCTION ReplaceMemory (S AS STRING, SearchFor AS STRING, ReplaceWith AS String) AS LONG

  LOCAL I AS LONG, L AS LONG, pSrc AS BYTE PTR, bSearch AS BYTE, bReplace AS BYTE

  L        =  LEN(S)
  pSrc     =  STRPTR(S) 
  bsearch  =  ASC(SearchFor)
  bReplace =  ASC(ReplaceWith)   

  FOR i = 1 TO L 
    IF @pSRC = bSearch THEN
       @pSrc = bReplace
    END IF 
    INCR pSrc
  NEXT
END FUNCTION

That's an interesting tidbit there about the use of ANY in REPLACE.... which reminds me....


...while I have not tested this in 8X, thru 7x REPLACE is 'blind', recreating the source string even if the 'search for' is not present and no replacement is needed.

Since INSTR is really, really quick, testing for replacement needed before doing so is another 'speed' tip...

   IF INSTR (mainstring, searchFor) THEN
      REPLACE searchFor WITH replaceWith IN MainString
   END IF

[John Gleason]

Quick tip: If you're doing a replace using strings of byte size, it is faster (over 3x faster) to use the ANY keyword.

Example:

REPLACE ANY $NUL WITH "." IN string4000
'was 3.2 times faster than
REPLACE $NUL WITH "." IN string4000

My string was 4000 long btw.
And it had a lot of $NULS.