[
Lists Home |
Date Index |
Thread Index
]
Rick Jelliffe writes:
> These two things conspire to make it that, for the lion's share of
> documents, by the time the SAX stream is finished, all the SAX
> events will be still in memory, though perhaps unreachable. If they
> are in memory, why not make them available?
I suppose someone could implement it that way, but it would be a very
naive implementation.
First, events are callbacks, not objects, though some specialized
objects (like an Attributes implementation) are involved. Second,
most SAX implementations (at least the ones that I've seen) reuse the
same objects over and over for each callback by simply changing the
data fields (a typical SAX driver will allocate only one Attributes
object for the whole parse). The key to speed, at least in Java, is
not to allocate new memory any more often than necessary.
That said, I did once build a DOM 1 implementation on top of a cached
SAX 1 stream. It was *much* faster (to build) and smaller than any
other DOM implementation I'd seen, but also read-only and a little
slower for access.
All the best,
David
--
David Megginson, david@megginson.com, http://www.megginson.com/
|
