Cart
[Home] [By Thread] [By Date] [Recent Entries]
David Megginson wrote, > Miles Sabin writes: > > For a one-shot application (ie. startup; process one document > > instance; terminate) the classloading overhead for the DOM API can > > be quite significant even with the most recent VMs. In some work > > I've done lately I've seen DOM classloading account for as much as > > 10% of wall clock time with the Sun 1.4.1_02 VM on Linux, Solaris > > and the other one. SAX, being a much smaller API, is at an > > advantage here. > > That's scary. I meant just the time for object allocation when > loading the XML document (a DOM tree contains a *lot* of objects). I > had not considered class loading overhead. Well, I guess I should emphasize that the case I was talking about there was fairly esoteric. In general, tho', it's not so much scary as inevitable. Consider a trivial document <foo>wibble</foo>. Now consider how many additional non-core classes and interfaces have to be dragged off disk, verified and initialized before you can do anything interesting with it via the DOM API. If the application itself is trivial, it shouldn't be all that surprising that DOM classloading has a measurable impact. On the bright side, it's quite possible that one aspect of this, http://www.jcp.org/en/jsr/detail?id=202 (see esp. section 2.5) will improve things significantly. Cheers, Miles
|
