[
Lists Home |
Date Index |
Thread Index
]
From: "Rich Salz" <rsalz@datapower.com>
> ... 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
|
