commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <robertburrelldon...@blueyonder.co.uk>
Subject Re: [digester] Are performance improvements wanted?
Date Sun, 12 Sep 2004 15:20:32 GMT
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message