Hi Paul, thanks for the good words!
That's an elegant solution - starting probe at 1 instead of in the middle,
to get the case where the key we want is already in the first file. I like
it. I had set up a test on my machine to try lots of different scenarios
with the original sort.c and my mo
Lemley James - jlemle <[EMAIL PROTECTED]> writes:
> I've coded a patch to sort.c from coreutils 5.3.0 for your careful
> consideration (and my use ;) to perform a binary search in the merge pass,
> only if the key was not found in the first merge temp file.
Thanks for that idea. How about the fo
Somewhat embarrassed by this, but that last sort.c patch I sent has been
de-uglified some. Try this one instead.
This patch is restructured slightly from the last one and performs even
better in my merge tests, both on random key files and dupe key files.
Sorry for sending that before I was
Hi coreutils hackers,
I see this topic has come up on the list before (searching for NMERGE in the
archives), but in coreutils 5.3.0 sort.c, temporary files are still merged
in a linear-search fashion. Admittedly I am new to this list and haven't
read every note, but I didn't find a reason fo
