Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!gem.mps.ohio-state.edu!ginosko!uunet!munnari.oz.au!cs.mu.oz.au!ok
From: ok@cs.mu.oz.au (Richard O'Keefe)
Newsgroups: comp.sources.wanted
Subject: Re: Looking for a better sort(1)
Message-ID: <2340@munnari.oz.au>
Date: 9 Oct 89 10:23:16 GMT
References: <110@pmdvax.UUCP>
Sender: news@cs.mu.oz.au
Lines: 16

In article <110@pmdvax.UUCP>, staylor@pmdvax.UUCP (Scott G. Taylor) writes:
> I am looking for a better sort(1) which will exploit free memory
> to increase speed.

Which sort(1) are you using?  The System V sort(1) has an option
	-y$MEMORY_TO_USE_IN_KILOBYTES
I recently posted a small fast sort (called nsort) to comp.sources.misc
-- somewhere along the way it lost a "}"; patch coming --
which slurps the entire file into memory, sorts it, and writes it out;
it is up to twice as fast as sort(1) even with the -y option because
(a) it is using strcmp() rather than a generic key comparison routine
(b) it uses a list merge rather than the misleading misnamed "quick"sort.

A device you might use is to break your file into chunks, read them in,
and sort them using a carefully crafted key comparison routine (nsort is
a good place to start), then use sort(1) just to merge the chunks.