home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!comp.vuw.ac.nz!waikato.ac.nz!aukuni.ac.nz!cs18.cs.aukuni.ac.nz!jwil1
- Newsgroups: comp.sys.acorn.tech
- Subject: Re: adfsbuffers
- Message-ID: <1992Dec22.212234.2185@cs.aukuni.ac.nz>
- From: jwil1@cs.aukuni.ac.nz (TMOTA)
- Date: Tue, 22 Dec 1992 21:22:34 GMT
- Sender: jwil1@cs.aukuni.ac.nz (TMOTA)
- References: <1992Dec18.113330@informatik.uni-kl.de><1992Dec20.011534.5366@cs.aukuni.ac.nz> <FL.92Dec21130356@pierre.tools.de>
- Organization: Computer Science Dept. University of Auckland
- Lines: 40
-
- fl@tools.de (Frank Lancaster) writes:
-
- >> That is, I
- >> get the impression that setting a large value for ADFSBuffers will NOT
- >> have ANY effect on a SINGLE file, but using (e.g.) 256 buffers will allow
- >> up to 256 files to be buffered simultaneously.
-
- >Actually adfsbuffers does have a dramatic effect on reading
- >and writing a single file. Using my RISC OS tar for a large hard disc
- >backup with compression, I normally set adfsbuffers to 255. Then
- >writing to the disc happens in the background and the compression
- >of a file can begin before the preceeding file has been completely
- >written to disc. This also works under taskwindows, so you get
- >somewhat better preemptive multitasking.
-
- ... you don't think, perhaps, that the significant improvement is due to
- the fact that you are reading multiple files and writing to 1? And
- that the more buffers you have, the more files can be buffered before
- buffers have to be flushed?
- Remember that read-buffers should make a difference if you're using a
- FS that supoprts read-ahead...
-
- Perhaps ADFSBuffers IS able to use more than 1 "1kB buffer" on a single
- file (i.e. actually use a 256kB write buffer for a single file), but this
- is not aparrent from the help on the configure option...
-
- (Also, I would think that tar would be slightly different anyway, as it's
- a C program, and if it uses stdio then it's likely that C would be
- providing buffers, in which case, I would assume you're using setvbuf()
- to allocate large I/O buffers in order to improve the throughput...)
-
- Also, I have found with that sort of disc operation (reading, writing are
- interleaved a lot) that a slight increase in buffer size can be all that
- is needed to drop below the 'thrashing' threshold, and the amount of seeking
- necessary drops considerably, thus speeding up the process a lot.
- (With !CBAdecode, the difference between 4kB buffers and 16kB is amazing)
- --
- _________________ "I'd like to answer this question in two ways:
- /____ _ _/_ __ First in my normal voice, and then
- // / //_//_ /_/ in a silly, high-pitched whine." (Monty Python)
-