From: "Carlos Myers" <farix@CITYNET.NET>
> From: "Torgny Bjers" <artovil@ARCANEREALMS.ORG>
> > On 03-04-21 00.18, "Carlos Myers" <farix@CITYNET.NET> wrote:
> >
> > I am not entirely sure. But could it have to do with porting to Windows?
I
> > think that some of the diskio routines don't work straight out of the
box
> > for Windows, but maybe that's not it. Just a shot in the dark.
>
> Sammy's original diskio routines didn't work straight out of the box for
> Windows, and I believe several other platforms. So that couldn't have
been
> the reason.
>
I think Sammy gives the answer himself:
/*
diskio.c Fast file buffering
(C) Copyright 1998 by Brian Boyle
Version 1.3
*/
As opposed to the stock code's use of fopen(), fclose(), fgets() etc.,
which first opens a file, then reads small chunks, processes each chunk,
then closes the file, Sammys code loads the whole file to memory on
fbopen(), then makes alterations in memory (reads/writes/appends), and
writes the whole file on fbclose().
Due to the way computers - and especially harddrives[1] - work, it is
considerably faster to avoid reading from the same file multiple
times. This is even more true on OS'es as complex as *nix and windows,
since these might allow other processes access to the disk in between
reads, making access time even slower.
These routines deserve a wider audience, if you ask me.
Welcor
[1] Access times on large (new) drives are in the area
of 5-15 milliseconds(average 8,5). On a multitasking
computer, it is not rare for a couple of hundred processes
to be running at the same time, or rather, in fast sequence,
each getting a small portion of the cpu time. If one of these
processes needs diskaccess, it connects through the proper
interface, which then looks up the relevant part of the disk.
This process takes the above 8,5 ms. If another process then
wants diskaccess, the interface will have to find back to the
place currently being read from, next time around, again using
8,5 ms to find it.
Luckily the makers of harddrives have realised that this is a
terrible waste of time, and so have included built-in caches
on the harddrives themselves, guessing what you might want to
read next, and storing it in a small, fast memory, typically
either 2 or 8 MB, the larger the disk, the larger the cache.
So now you're thinking, ok, so the harddrive manufacturers
have dealt with the issue, so I don't have to bother, right?
Wrong! Even the best cache can only guess at the next part
you want to read. If you code using internal file buffers,
the cache can guess whatever it likes, it doesn't matter. You
have made sure that regardless if there are 100 other programs
wanting access to the harddrive, you're not in line anymore.
After all, you're a better guesser than the cache, since you
_know_ what you'll be reading next.
All that accomplished by a small diskio library. Kudos to Sammy.
Oh, you already knew that? Sorry, didn't mean to sound patronizing.
--
+---------------------------------------------------------------+
| FAQ: http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html |
| Archives: http://post.queensu.ca/listserv/wwwarch/circle.html |
| Newbie List: http://groups.yahoo.com/group/circle-newbies/ |
+---------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 06/26/03 PDT