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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
