buffered input

Michel Fortin michel.fortin at michelf.com
Sat Feb 5 06:28:41 PST 2011


On 2011-02-05 07:01:24 -0500, spir <denis.spir at 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.fortin at michelf.com
http://michelf.com/



More information about the Digitalmars-d mailing list