In message <[EMAIL PROTECTED]>, "Duke Tantiprasut" writes: >I'm curious why there is such a significant jump from the Perl5Matcher >compared to the java.util.regex?
A hefty chunk of that time comes from converting strings to char[] before matching. I've tuned that benchmark before and trimmed 25% of the time just by using PatternMatcherInput instead of String. It's not exactly a rigorous benchmark anyway. Measurements I've made in the past show that the performance of the packages depends heavily on the input and how the regular expressions are written. Two equivalent regular expressions can have very different performance characteristics. That said, ORO is behind the times on performance, having been designed originally to get the most out of JDK 1.0.2. A question that bears revisiting is if Perl5Matcher needs to bother converting to char[] anymore. In JDK 1.0.2 and 1.1 days it was a big performance win, but unless you're working with your input as char[] from the start, I bet these days it would be faster to not make the conversion and work directly with String (or CharSequence) if we're willing to abandon JDK 1.2/1.3 compatibility. But now that there's a java.util.regex, the primary reason to use ORO appears to be if you're still on 1.2/1.3... In response to the email Subject, Perl5Util is a convenience class and will always be slower than using Perl5Matcher directly because Perl5Util has to parse the native Perl-style representation of expressions :( daniel --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
