Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!usc!cs.utexas.edu!csd4.milw.wisc.edu!schaefer!larry!jwp
From: jwp@larry.sal.wisc.edu (Jeffrey W Percival)
Newsgroups: comp.unix.wizards
Subject: Re: Algorithm needed: reading/writing a large file
Message-ID: <207@larry.sal.wisc.edu>
Date: 7 Jul 89 20:41:12 GMT
References: <205@larry.sal.wisc.edu> <8137@bsu-cs.bsu.edu>
Reply-To: jwp@larry.sal.wisc.edu.UUCP (Jeffrey W Percival)
Organization: Space Astronomy Lab, Madison, WI
Lines: 22

In article <8137@bsu-cs.bsu.edu> dhesi@bsu-cs.bsu.edu (Rahul Dhesi) writes:
>In article <205@larry.sal.wisc.edu> jwp@larry.sal.wisc.edu (Jeffrey W
>Percival) writes:
>[how do I sort a large file that won't fit in memory?]
>There are many variations on the merge sort.  Here is a simple one:

Please be careful with your paraphrasing.  I did not ask how to sort a
large file that won't fit in memory.  I said I already had a fast and
efficient sort and that the sorting was already known.  My question was
about optimizing the process of rearranging a disk file according to a
*given* mapping.

One helpful person suggested reading sequentially and writing randomly,
rather than vice-versa, and I tried that but it didn't help.  I guess
the benefit gained from using the input stream buffering was cancelled
out by the effective loss of the output stream buffering.

The ever-attentive and always-reliable Mr Torek suggested looking
into disk cache algorithms in OS journals, and verily that I will do,
with thanks to those who responded.
-- 
Jeff Percival (jwp@larry.sal.wisc.edu)