Digester overhead

[Jim Henderson <jg...@metafile.com>]

Can anyone offer a guess of how much slower it is to use a Digester rather
than writing individual SAX custom document content handlers?  Assuming all
of the classes are loaded and retained would using a digester cause
considerable overhead?

I am writing my first SOAP web service and have no experience to make a
judgment which direction to go.

Thanks,
Jim



---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-user-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-user-help@xml.apache.org

Re: Digester overhead

[Simon Kitching <si...@ecnetwork.co.nz>]

On Wed, 2004-09-22 at 11:04, Paul R Brown wrote:
> Hi, Jim --
> 
> > Can anyone offer a guess of how much slower it is to use a Digester 
> > rather
> > than writing individual SAX custom document content handlers?  
> > Assuming all
> > of the classes are loaded and retained would using a digester cause
> > considerable overhead?
> 
> The really short answer is YMMV.  The slightly less short answer is 
> that Digester is probably fast enough.  Unless you're an experienced 
> SAX programmer, the time you'll spend writing and rewriting a 
> hand-implemented solution will outweigh the nominal performance gains.  
> (S in SAX is for "simple", but that's the API as opposed to its usage.)
> 
> On premature optimization:
> 
>    http://c2.com/cgi/wiki?PrematureOptimization
> 
> I recently made the decision to hand-implement a SAX-based loader for a 
> configuration object model, but I made that decision based on a desire 
> to minimize library dependencies (JAXB, JIBX, XMLBeans, Digester, 
> etc.).  Otherwise, I would have gone with a framework.

I would expect Digester to have some overhead. The most significant
issues will be:
* determining which rules are matched by each element detected
* using reflection to set fields instead of direct calls

However the savings in developer time of using Digester over custom SAX
code will be immense. Only if you are shipping hundreds or thousands of
copies of the software are you likely to save money by optimising the
code in such a labour-intensive manner.

Another option is to go for "code-generating" xml->java products such as
JAXB (http://java.sun.com/xml/jaxb/). Here's an article that compares a
number of alternative libraries:
  http://www-106.ibm.com/developerworks/xml/library/x-databdopt/
 
Also try googling for "xml java binding".

The "code-generation" approach is somewhat clumsier to use in my
opinion, particularly if your schema later changes. However it is likely
to approach or even exceed the speed of hand-written code whereas
Digester *does* have an overhead.

Personally, if you are only processing "configuration" information (ie
are doing it only once at startup) then I would suggest that your time
could be invested far more profitably in other parts of the application
than optimising the parsing of the configuration.

Regards,

Simon


---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-user-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-user-help@xml.apache.org

Re: Digester overhead

[Paul R Brown <pr...@fivesight.com>]

Hi, Jim --

> Can anyone offer a guess of how much slower it is to use a Digester 
> rather
> than writing individual SAX custom document content handlers?  
> Assuming all
> of the classes are loaded and retained would using a digester cause
> considerable overhead?

The really short answer is YMMV.  The slightly less short answer is 
that Digester is probably fast enough.  Unless you're an experienced 
SAX programmer, the time you'll spend writing and rewriting a 
hand-implemented solution will outweigh the nominal performance gains.  
(S in SAX is for "simple", but that's the API as opposed to its usage.)

On premature optimization:

   http://c2.com/cgi/wiki?PrematureOptimization

I recently made the decision to hand-implement a SAX-based loader for a 
configuration object model, but I made that decision based on a desire 
to minimize library dependencies (JAXB, JIBX, XMLBeans, Digester, 
etc.).  Otherwise, I would have gone with a framework.

> I am writing my first SOAP web service and have no experience to make a
> judgment which direction to go.

That's a more interesting question.  Maybe come over to the AXIS user 
list?

---
Paul Brown
http://blogs.fivesight.com/pbblog


---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-user-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-user-help@xml.apache.org