You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?).
The text was updated successfully, but these errors were encountered:
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.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 callsString#charAt
, the internal implementation would probably not be that complicated. We might have to support an alternate version of thePattern
interface that acceptsbyte[]
(I don't think we'd want to include thebyte[]
based methods on the standard interface?).The text was updated successfully, but these errors were encountered: