Matcher[String] with regex's

[Adam Rosien]

Why are Matcher[String] that use regex's (BeMatcher, FindMatcher, etc.) defined with by-name parameters? This causes the patterns to be compiled for every execution of the matcher, rather than just once.

.. Adam

[etorreborre]

There's no strong reason why this parameter should be by name. I think the original motivation was to avoid evaluating anything in case of an expression like "aMatcher or bMatcher" when "aMatcher" matches ok.

However even if the parameter was not by-name, you would get several pattern compilation anyway, everytime "a matches b" is called.

If you download 1.9-SNAPSHOT, you'll get an optimized version when I compile the Pattern once for each created matcher so that it can be applied several times at no cost.

I also extended the API to accept java.util.regex.Pattern object or scala.util.matching.Regex.

Did you find about this by running the Sniff code?

Eric.

[Adam Rosien]

I didn't find it directly via sniff, but when trying to figure out what is making sniff so slow at scanning files (still investigating...). I was worried that re-creating the Regex/Pattern was expensive, but for my tests it didn't seem to be the case when I created my own matchers that didn't use call-by-name.

According to the source of Regex, the Pattern object is created (the expensive compile) during Regex construction, in case you might have assumed otherwise.

Back to my investigations...

.. Adam

[etorreborre]

> According to the source of Regex, the Pattern object is created (the expensive compile) during Regex construction, in case you might have assumed otherwise. 

Yes I saw that, and also, since this is not a lazy val, it may blow up before you even use it (if the Pattern doesn't compile).

Eric.

[Adam Rosien]

Also, using String.matches() recompiles the pattern every time.

[Daniel Sobral]

Note that this pattern recompilation is very common in normal Scala
code, due to how easy it is to use regex patterns in place.

Just assign the regex to a val, and use that val instead elsewhere.

--
Daniel C. Sobral

I travel to the future all the time.