commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reid Pinchback <>
Subject Re: [digester] Are performance improvements wanted?
Date Sun, 12 Sep 2004 20:38:01 GMT

--- robert burrell donkin
<> wrote:

> 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

Ok, I'll see what I can come up with.   First I'm
trying to finish off one of the Digester 1.7 issues 
listed on the Wiki (can Digester deal with Ant
properties?).  I hope to have that finished today.

The nature of performance improvement investigations
tends to be "I won't know if its faster until I know
if its faster".  The typical, easy approach is to 
find bits of calculation that can be migrated from
more-frequently-executed areas to something less
frequent.  Another, sometimes tougher approach
is to find ways of eliminating freqently-invoked
runtime casts.  You can also get amazing changes
by rewriting 'for' loops, but that tends to be an
all-or-nothing thing; 10x better, or no change
at all.  I'm also inclined to see how much
rule match processing factors into Digester
performance.  In any case, I'll follow your advice
and submit smaller changes if I find anything.

> 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.

The first performance-related patch I'll submit 
shows how I approximate this.  Mostly I try to
minimize how much JIT, GC, and differences in
inheritance hierarchy depth can distort the
comparison.  The case I've put together is on 
what the impact would be of handling logger
initialization statically in the Digester class.
Not a big win, obviously, but an easy example of 
the approach.  Besides cutting constructor cost 
in 1/2 is never bad.

Somebody suggested JPerfUnit; I've used it, but
haven't been all that impressed by it.  I think
its decent for monitoring performance on large
connected hunks of code, but not really any
good at helping you investigate how to speed
code up.  Invoking all the surrounding unit test
boilerplate just distorts the results too much.
While you hope to find 1 or 2 places in the
code that account for a large hunk of performance,
often you instead end up finding 20 or 30 places
that, in total, get you the desired change.
JPerfUnit is too coarse for that kind of work.

More effective is to just go and grab the free 
copy of JProbe, and use it profile a suite of
unit tests to get some ideas.  Then you create
some carefully-designed unit tests that let you
compare before-and-after timing results.  The
unit tests don't have to depend on a commercially
produced tool, I just use it for an initial
"sniff test" because it lets me prune out
irrelevant CPU loads (like time spent on
unit test boilerplate).

Do you Yahoo!?
Read only the mail you want - Yahoo! Mail SpamGuard. 

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message