On 2011-02-05 07:01:24 -0500, spir <denis.s...@gmail.com> said:

On 02/05/2011 08:45 AM, Michel Fortin wrote:
One thing I'm wondering is whether it'd be more efficient if we could provide
our own buffer to be filled. In cases where you want to preserve the data, this
could let you avoid double-copying: first copy in the temporary buffer and then
at the permanent storage location. If you need the data only temporarily
however providing your buffer to be filled might be less efficient for a range
that can't avoid copying to the temporary buffer for some reason..

Does this also makes sense when one needs to iterate over a whole set of source data via buferred input rangeS? I mean the same buffer can be reused, avoiding repeted allocation (or is this wrong or irrelevant?).

As I said in my post, whether a temporary buffer or a user-supplied buffer is better depends on whether you plan to store the data beyond the temporary buffer's lifetime or not. If you just iterate to calculate the SHA1 hash, the temporary buffer is fine (and possibly better depending on the range's implementation). If you iterate to calculate the SHA1 hash *and* also want to store the file in memory, then it's better if you can provide your own buffer which can point directly to the permanent storage location and bypass copying to the temporary buffer (if the range's implementation allows it).

--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/

Reply via email to