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]
