Cart
[Home] [By Thread] [By Date] [Recent Entries]
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@m..., http://www.megginson.com/
|
