[prev in list] [next in list] [prev in thread] [next in thread] 

List:       jakarta-oro-user
Subject:    Re: Perl5Util performance
From:       "Duke Tantiprasut" <duketantiprasut () gmail ! com>
Date:       2006-03-31 17:39:32
Message-ID: 824028f0603310939q25e01339kc4a0a75e3c31d66e () mail ! gmail ! com
[Download RAW message or body]


Hi Daniel,

I think I'm going to stick it out with oro/perl5util. I prefer to provide
the flexibility and perl5 familarity than a little extra speed at this
stage. Do you know when you'll get the chance to look at the changes to mak=
e
it more multi-thread friendly?

With Perl5Util, doesnt that generate the patterns that cached and used the
Perl5Matcher? i.e. am I correct in assuming that the penalty is only during
the initial pattern generation and not during subsequent matching?

Thanks

Duke

On 3/30/06, Duke Tantiprasut <duketantiprasut@gmail.com> wrote:
>
> Thanks Daniel.
>
> Sounds like I should be moving to java.util.regex. I do like the
> convenience of the pattern caching but I guess it's easy enough to set th=
at
> up myself for java.util.regex.
>
> Duke
>
>
> On 3/29/06, Daniel F. Savarese <dfs@savarese.org> wrote:
> >
> >
> > In message <824028f0603291030j5607dfd9g2e8208ff51f60320@mail.gmail.com>=
,
> > "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'r=
e
> > 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 Perl5Uti=
l
> > has to parse the native Perl-style representation of expressions :(
> >
> > daniel
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: oro-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: oro-user-help@jakarta.apache.org
> >
> >
>


[prev in list] [next in list] [prev in thread] [next in thread]