Matching against a byte[] is likely to have lower overhead than matching against a String, as the compiled code would no longer contain as much functionality inlined from String#charAt. If that's true, then it might sometimes be good to have a version of the code that operates on byte[] instead of String.
There are two cases you can imagine here:
- A caller might already have a
byte[], and want to match against it.
- It might be true that even if you already have a String, it's faster to convert to a
byte[]
I have no intuition whether the second possibility is ever true.
Since the current version of the code only cares whether it's getting data from a String when it calls String#charAt, the internal implementation would probably not be that complicated. We might have to support an alternate version of the Pattern interface that accepts byte[] (I don't think we'd want to include the byte[] based methods on the standard interface?).
Matching against a
byte[]is likely to have lower overhead than matching against aString, as the compiled code would no longer contain as much functionality inlined fromString#charAt. If that's true, then it might sometimes be good to have a version of the code that operates onbyte[]instead ofString.There are two cases you can imagine here:
byte[], and want to match against it.byte[]I have no intuition whether the second possibility is ever true.
Since the current version of the code only cares whether it's getting data from a
Stringwhen it callsString#charAt, the internal implementation would probably not be that complicated. We might have to support an alternate version of thePatterninterface that acceptsbyte[](I don't think we'd want to include thebyte[]based methods on the standard interface?).