[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Internal entities removed from XML?
From: "Rich Salz" <rsalz@d...> > ... if I have "&f;" expanding > to "foobar", and I want to implement in-place conversion, then I always > have to have a "lookaside" place, and my read-from-the-source routine > always has to look to see if the pushback is non-empty, etc. Only benchmarking/profiling can tell, as Tim points out. I would expect that if you used some kind of stack of iterators (e.g. over text segments) to implement your entities, that the extra level of indirection would not have a performance penalty (due to data-caching and pipelining in the CPU). In that case, the iterator only needs to check for the segment end, which is just the same test that a reference-less file would need. I have an interesting experience with the supposed cost of parsing to relate: this only happened a couple of weeks ago. We needed to get some data from a server, parse it, decorate it with some attributes. It ran like a dog, and one programmer attributed this to the slow speed of parsing. It turned out that we were adding UUIDs to most elements, and the UUID library we used could only allocate UUIDs at a rate of 1 every 10 ms (which has something to do with the time granularity of the UUID format being used). So it turned out that an innocuous-looking library was putting in 10ms delays every time a UUID was allocated. (We wrote a faster allocator with our own UID format.) But it really hit home to me that when mixing parsing and processing it is quite possible to get the wrong idea about where a bottleneck lies. Cheers Rick Jelliffe
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|