(If you don't care about the particulars, but have some Regex's you can
contribute, jump to the code bit. Thanks)
I have two implementations to test; one is a (somewhat) naive linked list
stack manager, the other is (as yet) still recursive.
The former works, but I put it together as a proof of concept and don't
trust it much. Fifty-two return points in one method is a tad much.
Implemented as a raw java.util.Stack is ten times as slow as the original,
and creating a private static LocalStack class as a LinkedList is twice as
slow.
Though, 10K runs of the first thousand chars of the two example regex
patterns take ~1.2 and 2.6 seconds, respectively. So .12ms and .26ms per
run. I'm rather set against ANY performance decrement, or I'd have just
verified that code and moved on.
The latter implementation is a refactor of the method to a single point of
exit. THAT goal is working, now I have to make sure that I can add values
to an internal stack manager without blowing away any state -- some of the
CASE statements are a mite obtuse, and I don't like using breaks much.
Breaks also seem to affect the ability of the optimizer to do its job, as
the last CASE I modified (op.CLOSURE) gave a 10% performance boost without
it. Although I'm suspicious, as it's late and now the stack overflows
somewhat (ok, a lot) earlier than before. I did add a number of variables,
so it's possible I made no mistake in the logic (I'd better not have!).
--- The request part ---
Regardless of the final form, I need to populate a test library:
I have a few regular expressions lying around, and I figure I'll parse in
a few of my XML files and modify the RegularExpression class to dump
anything it sees to a file... I still doubt I'd have more than 20, and
none of them shockingly complex.
So if you could send me your favorite regular expressions, along with a
couple of stings to match them against (some pass, some fail, but indicate
which), it would be a big help.
Even better, if you could format them like this sample:
testCases.add(new TestCase(
"Overall description",
"Your Regex Pattern",
new SubCase("A description", shouldPass, "matchString" ),
new SubCase("A description2", shouldPass, "matchString2" ),
... more SubCases ...
));
I would be able to paste them straight into the unit test and run them.
The SubCase argument uses varArgs, so add as many as you want/will. Feel
free to add your 'contributed by:' to the overall description area for
credit... Though I'd remind you not to include a parsable (or any, lest
random-someone ask you for help later) e-mail address on this list, as it
is public and archived.
My own direct e-mail address is (my first name @ my last name).biz. And if
someone has written a parser for THAT, they can have it.
The more complex your tests the better, for the beat down. Tailored
regex's would be grand for focused testing (e.g. the simplest lookahead,
lookbehind, singleline, multiline, etc). But I figure that's asking for
real work.
Also, or instead, if you have a 'regular expression rich' schema and
conforming xml file that you can send (think 'might become public'), I
should be able to parse those out without much trouble.
And yes (obviously), my test library uses 1.5 features... I'll convert it
if the changes are approved for commit. Keeps me sane.
Of course the changes to RegularExpression are using JDK 1.3 as a target,
as that is the lowest I've available. My memory of the differences between
1.2 and 1.3 are fuzzy, but I don't think anything I'm using has changed
since 1.0. My only real concern is that my JVM has a better optimizer and
could be hiding poor performance that I induce.
Thanks much,
--
Geoff M. Granum
760-534-1636
Portland, Oregon
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
