On 10 Sep 2004, at 18:18, Reid Pinchback wrote:
I just finished a project where I had to do a fair bit of performance tuning work over the last year. I was looking through the current digester source, and even without torquing the code wierdly or changing class APIs I've seen places that could probably be made faster.
1) Would folks be interested in digester performance fixes? No point in my wasting time on them if, for example, some major re-write is underway.
though there's probably going to be a radical rewriting one day (digester2), i (for one) will be willing to review and apply patches to the digester one code stream for the foreseeable future. IMHO digester 1 is approaching feature completeness (at least, given the limits of backwards compatibility) and should be continued to maintained as a mature, stable, well tested library. looking at performance issues now seems appropriate (though it's not a particular itch of mine and i'm not likely to spearhead any comprehensive effort).
2) What would be the preferred way of submitting them? I was thinking of submitting a tweaked class as an enhancement request with an attached patch and maybe a unit test that measured both the old and new code. People could use the test to try the changes on other platforms (I'd only be testing on some Win32 sdk versions, but the fixes I have in mind should either help or at least do no harm on other platforms).
i've been thinking about the problem of proving performance improvements by using unit tests for a while now. i'd really like to be able to be able to create reports about the current performance of library code. maybe it'd be possible to use some kind of normalization to eliminate (or at least reduce) platform specific differences. i'd be interested to hear comments from other folks about this (or ideally, hear about a tool out there which does this ;)
so, even if no tool exists (at the moment), it'd be great to have unit tests that demonstrate the performance improvement. that way, once a tool exists, we can just plug it straight in.
in terms of submitting patches, if you haven't take a look already, read the standard stuff on submitting patches on the web site and attach them to bugzilla enhancements. (IIRC the lists now strip most attachments to limit stress caused by viruses.) you might like to post an email to the list explaining the changes and linking to the request (bugzilla messages often slip through my filters). it's better to create many small requests (one per improvement) rather than one large one. it's hard to verify large patches and so they tend to get pushed down the priority list.
How much of a gain people would see in real use of course would depend on what they were doing; I'm expecting these fixes to matter more in situations where digesters would run frequently (e.g. SOAP) and developers have, where feasible, already dealt with the obvious (factoring out rule+parser factory+parser instantiations).
i think that it'd be an excellent idea to collate the collective community knowledge about real life digester performance. the wiki (http://wiki.apache.org/jakarta-commons) seems like the right place for something like this. it'd be really great if you could pull something together on this.
- robert
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
