The fastest entry is some 7-9 times faster than the RTL reference version (depending on the CPU). My own contribution scored less than 3 times faster... ;). Note that real-world speed gain will vary considerably - as always what you benchmark determines the results.
When that is said, Eric Grange's winning entry has some really neat tricks. The most important trick is to search for and store the position of all hits in the source string before allocating the result string and copying over the string data. Another is to use an upper-case character table to avoid pre-upping strings in the case-insensitive mode.
A much faster StringReplace can be nice, but before you jump in, consider if StringReplace really is the right tool for the job at hand. As Martin James put it in the delphi.non-tech newsgroup:
My response was:
"In anything other than trivial cases with small strings, I always use a char-by-char state machine anyway, certainly with HTML text parsing/tag handling. In such cases, any 'stringReplace' is hugely inefficient."
And on the FastStrings comment from my last blog entry, here are the results on one CPU:
"Yes, you are right. If you want performance, using StringReplace is most probably the wrong solution (no matter how fast it is). Most of the time you don't want to replace a single string, you want to replace a number of strings/patterns. A custom parser using a state-machine is often the best solution, performance wise. However, such optimizations might be prohibitively expensive to develop for simple problems where StringReplace will suffice."
P4 1600A Northwood
StringReplace_EG_MMX_1 8 671 1165 1836 // Eric Grange = 1836 ms
StringReplace_HV_IA32_1 4 2846 5018 7864 // Mine = 7864 ms
StringReplace_DKC_Pas_1 8 4565 4990 9555
FastAnsiReplace 0 4382 9248 13630 // FastStrings version = 13630 ms
StringReplaceRef 0 5523 9514 15037 // Bug-fixed RTL version = 15037 ms
StringReplaceRTL 8 6848 13336 20184 // RTL version = 20184 ms
So even my version kicked FastStrings ReplaceString... <bg>. And even as we speak, those delphi.language.basm folks are now cooperating to improve the blind-test winners few notches more...