On 12/12/05, Erik Huelsmann <ehuels@gmail.com> wrote:
> Some time ago, I created a translating stream. Just a few minutes
> ago, I committed an MD5 calculating stream. This is all part of a
> greater plan to reduce I/O in libsvn_wc by using more streams.
Kind of off-topic, but just to play the devil's advocate: if the
intent is to speed up Subversion, have you measured the effects of
your changes?
That is, assume that the temporary files' contents stay in the
kernel's block cache, so the whole operation is memory-to-memory
whether you use composed streams or temporary files. Making a series
of distinct passes over the full dataset (say, as one does when using
temporary files) gives you worse data locality, but better code
locality. Using composed streams gives you better data locality, but
worse code locality. If the common case is to operate on smallish
files (and most source files aren't that big), then gaining the data
locality wouldn't be worth it.
Understand, I'm not arguing that this is actually so. I'm just saying
that I can find an argument that doesn't seem totally dumb that this
might not be a speedup. It's certainly an increase in complexity;
aren't stream filters harder to write than functions that make a pass
over a file?
Of course, if the stream filters' buffers are so large that they
usually hold the entire file, then you've effectively replaced
temporary files with in-memory buffers, which seems like it would have
to be faster.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Dec 13 00:02:07 2005