questions about a backup program for the MS-DOS environment

[Joseph H Allen]

In article <2484 at dataio.Data-IO.COM> bright at Data-IO.COM (Walter Bright) writes:
>In article <12459 at wpi.wpi.edu> jhallen at wpi.wpi.edu (Joseph H Allen) writes:
><In article <1990Apr25.125806.20450 at druid.uucp> darcy at druid.UUCP (D'Arcy J.M. Cain) writes:
><<In article <255 at uecok.UUCP> dcrow at uecok (David Crow -- ECU Student) writes:
><<By using BUFSIZ instead of your own buffer length you get a buffer size
><<equal to what the fread and fwrite routines use.  
><No, no, no Yuck!  Don't use the C functions, and don't use such tiny buffers.
><(no wonder it's so slow :-) Try (in small or tiny model):
><	[asm example deleted]
>There is no point in going to asm to get high speed file copies. Since it
>is inherently disk-bound, there is no sense (unless tiny code size is
>the goal). Here's a C version that you'll find is as fast as any asm code
>for files larger than a few bytes (the trick is to use large disk buffers):
> [better C example deleted]

I didn't use asm to get the code itself fast.  The only reason I did it was so
that you can use 64K buffers in small/tiny model.  Now if only there was a
farread and farwrite call... 

I guess you can just compile the program in large model to have this same
effect (by habit I don't tend to use the large models).

Interestingly, this aspect of the copy program is one place where I think DOS
is sometimes faster than UNIX.  I suspect that many UNIX versions of 'cp' use
block-sized buffers. Doing so makes overly pessimistic assumptions about the
amount of physical memory you're likely to get.  

Of course, since DOS doesn't buffer writes it often ends up being slower
anyway (since it has to seek to the FAT so often).  'copy *.*' would be much,
much faster if only DOS was just a wee bit smarter...
-- 
jhallen at wpi.wpi.edu (130.215.24.1)