String replaceAll() vs. Matcher replaceAll() (Performance differences)

Question

Are there known difference(s) between String.replaceAll() and Matcher.replaceAll() (On a Matcher Object created from a Regex.Pattern) in terms of performance?

Also, what are the high-level API 'ish differences between the both? (Immutability, Handling NULLs, Handling empty strings, etc.)

coobird · Accepted Answer · 2009-09-23T16:22:31.850

101

According to the documentation for String.replaceAll, it has the following to say about calling the method:

An invocation of this method of the form str.replaceAll(regex, repl) yields exactly the same result as the expression
Pattern.compile(regex).matcher(str).replaceAll(repl)

Therefore, it can be expected the performance between invoking the String.replaceAll, and explicitly creating a Matcher and Pattern should be the same.

Edit

As has been pointed out in the comments, the performance difference being non-existent would be true for a single call to replaceAll from String or Matcher, however, if one needs to perform multiple calls to replaceAll, one would expect it to be beneficial to hold onto a compiled Pattern, so the relatively expensive regular expression pattern compilation does not have to be performed every time.

edited Sep 23 '09 at 16:22

answered Sep 23 '09 at 16:06

coobird

159,216
35
211
226

19

except, as mentioned below, the performance penalty of the pattern compilition. if you are using a constant regex, compile it and stick it in a static constant. – james Sep 23 '09 at 16:10
3

Your "Therefore" comment at the end only applies for 1 call, in which case performance metrics really aren't relevant. If there are repeated calls to replaceAll with the same regex then String.replaceAll is slower than caching a compiled pattern. – Jason S Sep 23 '09 at 16:10
Does anyone know if the `regex` String is static, are any javac compilers smart enough to figure out that the `Pattern` object can be static too and automatically build a static field into the generated bytecode? Sounds like a great way to boost performance on code while improving readability. – Nic Cottrell Jul 20 '14 at 13:56
I compared performance for String.replace() and the Matcher.replaceFirst() and the String version is significantly faster. – Wrench Oct 02 '14 at 14:49
2

Actually, with repeated use, holding onto the Matcher is even better. Create it with `Pattern.compile(...).matcher("ignored input")`, then use it with `theMatcher.reset(theString).replaceAll(...)` – aliteralmind Jul 01 '15 at 15:50
@aliteralmind you should make that an answer. I was reusing the pattern until I read what you wrote. – krispy Jun 16 '16 at 20:17
@krispy i've since changed my mind on this. Reusing the matcher is indeed a tiny bit more efficient, but it is much more clunky, especially because it requires the unused/dummy string. Reusing the pattern is your best bet. – aliteralmind Jun 16 '16 at 20:18
@aliteralmind that's really interesting, because it seems to make a significant difference in ms runtime when the replaceAll() is being called continually inside of an O(n^3) algorithm. I plan to stay with the matcher until I can look into the implementation code and see what the actual difference is. – krispy Jun 17 '16 at 00:05
3

@aliteralmind FWIW holding on to the Matcher is NOT threadsafe. We found this out the hard way in production and caused some corrupt XML strings. See http://www.javamex.com/tutorials/regular_expressions/thread_safety.shtml – matrixanomaly Oct 17 '17 at 05:38
@matrixanomaly I think the best here is to store Pattern to a constant and keep Matcher being created in local scope – deFreitas Apr 04 '21 at 14:59

score 31 · Answer 2 · answered Sep 23 '09 at 16:08

Source code of String.replaceAll():

public String replaceAll(String regex, String replacement) {
    return Pattern.compile(regex).matcher(this).replaceAll(replacement);
}

It has to compile the pattern first - if you're going to run it many times with the same pattern on short strings, performance will be much better if you reuse one compiled Pattern.

score 10 · Answer 3 · answered Sep 23 '09 at 16:07

10

The main difference is that if you hold onto the Pattern used to produce the Matcher, you can avoid recompiling the regex every time you use it. Going through String, you don't get the ability to "cache" like this.

If you have a different regex every time, using the String class's replaceAll is fine. If you are applying the same regex to many strings, create one Pattern and reuse it.

answered Sep 23 '09 at 16:07

erickson

265,237
58
395
493

1

Patching up your answer to repeat what I've already said is lame. – erickson Sep 23 '09 at 16:10
If that was aimed at me for some reason, I suspect I was already editing by the time you posted your answer... – Jon Skeet Sep 23 '09 at 16:46
Actually, it was aimed at coobird. – erickson Apr 15 '14 at 17:19

score 6 · Answer 4 · edited May 23 '17 at 11:54

Immutability / thread safety: compiled Patterns are immutable, Matchers are not. (see Is Java Regex Thread Safe?)

Handling empty strings: replaceAll should handle empty strings gracefully (it won't match an empty input string pattern)

Making coffee, etc.: last I heard, neither String nor Pattern nor Matcher had any API features for that.

edit: as for handling NULLs, the documentation for String and Pattern doesn't explicitly say so, but I suspect they'd throw a NullPointerException since they expect a String.

score 5 · Answer 5 · answered Sep 23 '09 at 16:05

The implementation of String.replaceAll tells you everything you need to know:

return Pattern.compile(regex).matcher(this).replaceAll(replacement);

(And the docs say the same thing.)

While I haven't checked for caching, I'd certainly expect that compiling a pattern once and keeping a static reference to that would be more efficient than calling Pattern.compile with the same pattern each time. If there's a cache it'll be a small efficiency saving - if there isn't it could be a large one.

score 5 · Answer 6 · answered Sep 23 '09 at 16:35

The difference is that String.replaceAll() compiles the regex each time it's called. There's no equivalent for .NET's static Regex.Replace() method, which automatically caches the compiled regex. Usually, replaceAll() is something you do only once, but if you're going to be calling it repeatedly with the same regex, especially in a loop, you should create a Pattern object and use the Matcher method.

You can create the Matcher ahead of time, too, and use its reset() method to retarget it for each use:

Matcher m = Pattern.compile(regex).matcher("");
for (String s : targets)
{
  System.out.println(m.reset(s).replaceAll(repl));
}

The performance benefit of reusing the Matcher, of course, is nowhere as great as that of reusing the Pattern.

score 0 · Answer 7 · answered Dec 01 '16 at 18:33

The other answers sufficiently cover the performance part of the OP, but another difference between Matcher::replaceAll and String::replaceAll is also a reason to compile your own Pattern. When you compile a Pattern yourself, there are options like flags to modify how the regex is applied. For example:

Pattern myPattern = Pattern.compile(myRegex, Pattern.CASE_INSENSITIVE);

The Matcher will apply all the flags you set when you call Matcher::replaceAll.

There are other flags you can set as well. Mostly I just wanted to point out that the Pattern and Matcher API has lots of options, and that's the primary reason to go beyond the simple String::replaceAll

String replaceAll() vs. Matcher replaceAll() (Performance differences)

7 Answers7

Linked