FidoNet Echomail Archive
aust_c_here

<<< Previous Index Next >>>

From: Frank Adam
To: David Nugent
Date: 1997-05-08 13:39:08
Subject: setvbuf()

On May 05 02:32, 1997, David Nugent of 3:632/348 wrote:
G'day David ,

>> If i have a buffer which is 50000 bytes and used for both
>> binary read/write,
>> should i let setvbuf() buffer the lot ? The buffer *is*
>> expected to fill up most of the time.

DN> Typically, BUFSIZ buffers are more or less optimal. Larger than that 
DN> and you may or may not see any gain.
Thanks for that, i've played around with it and settled on a 16K buffer
larger buffer reduced performance by a big margin, smaller by not that much.
>> 2. Is there a potential problem when using larger buffers especially on
>> an output stream ?

DN> There shouldn't be.
DN> If the output is corrupted, then it sounds like a bug regardless. 
DN> Whether it is a problem with the implementation's library or yours is 
DN> something you have to determine.
Yep, it was a bug in my verifying the data, the write itself was ok.
It's a file copy program, now slightly quicker on big files than DOS even
with screen writes. Now my problem is, how can DOS verify a 12Meg file 
copy in just over a second ? Takes me 27-28 seconds to copy, DOS 
takes 30-31. With verify mine takes an extra 20seconds, against 1 or 
2 from DOS.
I'm a bit sus about that verify, unless this is the latest undocumented 
DOS function which can byte compare 12M in 1 second. ;-)
I could also be using the wrong method but...nah.:-)   

 Regards, Frank

--- Msged 4.00
 * Origin: The ticking point, Melbourne, Australia. (3:635/728.21)
SEEN-BY: 633/267 270
@PATH: 635/728 633/267


<<< Previous Index Next >>>