Path: utzoo!attcan!uunet!lll-winken!lll-lcc!ames!mailrus!uflorida!novavax!proxftl!bill
From: bill@proxftl.UUCP (T. William Wells)
Newsgroups: comp.lang.c
Subject: Re: Value of microeffiency (was: Re: Optimal ...)
Summary: That's me out there
Message-ID: <472@proxftl.UUCP>
Date: 15 Jul 88 02:24:38 GMT
References: <163@navtech.uucp> <2775@ttrdc.UUCP> <164@navtech.uucp> <4616@b-tech.UUCP>
Organization: Proximity Technology, Ft. Lauderdale
Lines: 30

In article <4616@b-tech.UUCP>, zeeff@b-tech.UUCP (Jon Zeeff) writes:
) In article <688@clsib21.UUCP> ebg@clsib21.UUCP (Ed Gordon) writes:
) >
) >>>   A linked-list sort?
) >>>
) >>>   Once upon a time I got very tired of the slowness of the
) >>>   UNIX sort program. So I wrote a clone of it. I invented a
) >>>   whole new algorithm for it which you could call a
) >>>   linked-list merge sort.  It beat every other sort method
) >>>   that I tested hands-down.  Its only drawback is the
)
) If it's that good, perhaps someone could post a copy to comp.unix.sources,
) preferably in a form that is a plug in replacement for qsort().

That's me speaking, not Ed Gordon.  However, I might go ahead and
publish it.  There is one minor gotcha: the drawback, not copied
in the message above, is that the routine has got to get memory
for the linked list.  On virtual memory systems, this could cause
my sort to be significantly slower than on non virtual memory
systems.  There is also the overhead of actually allocating the
memory; while it ought not be significant, you never know.  (The
original implementation was on a non virtual system and the
linked list was allocated at the same time as the pointers to
the strings being sorted.)

Do you think I ought to post it over here so that you guys can
attack it before I submit a final version to the archives?  If I
do, I might also send over a qsort (created by disassembling
somebodies, I forget whose, library) that I have.  It might be
interesting to beat on both pieces of code and to compare
benchmarks of the final sort routines.