On Tue, Aug 17, 2010 at 11:57:11PM +0200, Stefan Fuhrmann wrote: > I overgeneralized my use-case here: I actually needed "move forward" only. > The concept of "skip N bytes", however, is perfectly in line with > the general > stream semantics. Because this also fits my needs, I changed the API in > r986485 accordingly.
But the stream implementation may still need to read all bytes until N anyway, to make sure the internal state is still valid after moving to offset N. Of course, we could say that a stream implementation is free to optimize for this use case if possible, but allow wrapper streams to override the "move forward" implementation. For instance, a stream wrapping an APR file would support "move forward", but as soon as you wrap this APR file stream with a translation stream, the translation stream's semantics take over and the APR file stream will effectively be read byte-per-byte when the "move forward" method is called on the translation stream. This would allow the translation stream to keep its internal state intact during a "move forward" operation. Performance benefits would then depend on the type of stream being used. Does this make sense? > The problem is that a lot of parser code would need to change at least its > function signatures to string buffers and offsets instead of > streams. I'm not > even sure that all streams are based on strings; some may be parsed on > APR file as well and use the same parser code (e.g. read hash from stream). Sure, that's what I meant. The patch code for instance uses multiple streams all mapped onto a subset of a file, and each such stream does special filtering and transformations on the text read from the file. See the definition of svn_hunk_t in include/svn_diff.h. Stefan
