Daniel F. Savarese wrote: > I have thought about the possibility of compiling the interpreted > op codes into Java byte-code, but I've never explored it. It should > be doable and very fast, but I don't know about the memory footprint > since you'd be creating a new class for each pattern.
this is an option for the .net regexp api. it would definitely be nice to see in ORO, specifically for projects that use regexps that are known at compile time. it may even be efficient to generate and load a bytecode compiled regexp class at runtime in cases where the same regexp is repeatedly used. a while back I played around with implementing simple bytecode compiled glob matching, and boyer-moore exact string macthing with compiled classes using bcel. I didnt have anything to bench the glob matcher against, and the boyer-moore was much faster than String.indexOf, but I never got around to building a pure java source version of boyer-moore search to compare how much faster the precompiled version was. one of the advantages of using the precompiled approach, at least in the boyer-moore case, is that I didnt need to produce 65k large shift tables for each character in the unicode character set, instead I used the lookupswitch bytecode op. which definitely saves on runtime mem usage. Dave -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
