Announcement

Collapse
No announcement yet.

REPLACE ANY vs. just REPLACE

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Gösta H. Lovgren-2
    replied
    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)
    =============================

    Leave a comment:


  • Michael Mattias
    replied
    >Still function calls though

    Where?

    PEEK(LONG, STRPTR(S) + iOffset)
    is the same as
    Code:
    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

    Leave a comment:


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

    Leave a comment:


  • Michael Mattias
    replied
    . 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...
    Code:
     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.

    Leave a comment:


  • Roger Garstang
    replied
    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.

    Leave a comment:


  • John Gleason
    replied
    >> 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.

    Leave a comment:


  • Michael Mattias
    replied
    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

    Leave a comment:


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

    Leave a comment:


  • Michael Mattias
    replied
    If you are restricted to BYTES it might be even faster to ..
    Code:
    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...

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

    Leave a comment:


  • John Gleason
    started a topic REPLACE ANY vs. just REPLACE

    REPLACE ANY vs. just REPLACE

    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:
    Code:
    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.
    Last edited by John Gleason; 13 Nov 2007, 07:34 PM. Reason: Only works exactly the same with byte size replacements
Working...
X