You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oro-dev@jakarta.apache.org by "Daniel F. Savarese" <df...@savarese.org> on 2002/07/04 20:21:42 UTC

Re: jakarta-oro performance (fwd)

In message <9B...@PARSV011>, Stephane Bailli
ez writes:
>For the records, when you say "can regain the performance lead", do you mean
>that you have some figures with other packages ? If yes could you give use
>more info ?

Jeffrey Friedl (author of Mastering Regular Expressions) claims that
the J2SE 1.4 java.util.regex package is faster, but he doesn't make his
benchmarks publicly available because he doesn't have the time to deal
with questions or other support.  I trust him, but I think a contributing
factor to the performance discrepancy is simply this char[] conversion
issue.  Eliminate that and with HotSpot 1.4 JVM my intuition is that
jakarta-oro will be comparable or faster for most cases.  Traditionally,
the Perl-style byte-code based NFA approach used by Perl5Matcher has beaten
out object-based NFAs like the 1.4 implementation.  But it's hard to say
how the new HotSpot optimizations will affect that.  All I know for sure
is that the toCharArray() approach in Perl5Matcher is now a loser.  I
haven't gotten around to seeing what the impact of moving to a generic
CharSequence instead of direct array indexing will do.  If HotSpot does
everything its performance docs claim, there should be little difference,
but I don't understand how HotSpot inlines virtual method calls when
different interface implementations may be called from the same generic
code.

daniel



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>