Thanks. I'll have a look monday/tuesday next week and let you know if I run into any hiccups.
Duke On 4/1/06, Daniel F. Savarese <[EMAIL PROTECTED]> wrote: > > > In message <[EMAIL PROTECTED]>, > "Duke > Tantiprasut" writes: > >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? > > I made the change on the trunk this morning. You'll have to check it > out with svn and compile it. I don't know when we'll be cutting a new > release. Everything related to ORO is done based on user demand. The > change could always be backported to produce a 2.0.9 release because > the trunk has changes in it that aren't appropriate for 2.0.9 and > may still change (the engine wrapper interfaces and the implementation of > a wrapper for java.util.regex). However, the trunk is stable (i.e., no > more bugs than 2.0.8), so it's safe to use as you would 2.0.8 even though > the new stuff may change. Just read the CHANGES file for a list of > additions. > > >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? > > Yes, that is correct. The patterns are generated only the first time > they are used (or if they subsequently get kicked out of the cache). > I don't know how bad of a performance hit the synchronized method calls > are these days, but it would have helped in 1.0.2, 1.1, and probably 1.2 > to have avoided synchronizing the methods. But Perl5Util was a > user-requested class (AOL actually asked for it) and the whole idea at > the time was that if you wanted performance, you should use a separate > matcher in separate threads. In general, my preference is to push thread > concerns out of libraries and into applications as much as possible, but > given the nature of Perl5Util, it does seem kind of weird to me now that > it uses synchronized methods everywhere and doesn't just use a separate > matcher for each thread. On the other hand, if it were to do that, then > it would be better for Perl5Util to be unsynchronized, leaving it to the > application to create thread-local Perl5Util instances. But the request > at the time was to be able to use a single class instance to perform > matches in multiple threads. Less RAM back in those days. > > daniel > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
