🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.lang.pascal.borland
Article #334

Sorting - Big files

#334
From: Robert AH Prins
Date: Thu, 15 Apr 1999 00:00
61 lines
3202 bytes
In reply to a private email from a person who knows he can interrupt me. (but
should have added to the tread...)

Hi M,
>
> I saw your post in clpb on sorting:
>
> > Of course you've got a problem if your file contains more than N
> > records or if you've got limited memory. (With both the original
> > and the upcased name the record will have a size of 44 bytes,
> > limiting N to, depending on other global variables, somewhere
> > around the 1450)
> >
> > Any clues? Give it a try and come back if you're really stuck.
>
> How do you sort arrays larger than available memory?

You cannot have an array that is larger than available memory :-)

> I know it can be done, since I downloaded several sort programs from
> Simtel that do so. But if you can explain, then I (and probably a
> bunch of people in the newsgroup) would very much like to know how!

If your file exceeds available direct access memory, you will have to
settle for a multipass merge sort, in _very_ simplistic terms:

- read in as many records as allowed by available RAM
- sort them and write them out to file 1
- read in a next bunch of records
- sort them and write them out to file 2
- repeat above until entire original file has been processed.
- open files created
- read one record from each of them
- write out the smallest of these and read the next record from the
  file that delivered it
- repeat previous step until all files have reached eof

Of course you may in this scenario encounter other problems - too many
open files, in which case you would only merge the first so many files
into one, before repeating the exercise with the next bunch. And yes,
you can already do the first merge-pass with the data from file 1 and
the sorted data from the next bunch...

Of course it's far easier to download RPSRT102.ZIP and SPWNO413.ZIP and
use the latters EXEC(...) executing RPSORT to do your sorting... <G>

And if RPSORT isn't fast enough, it contains the full source, so you
can tweak it for even higher performance.

BTW, I once tested it with a 250 Mb file filled with garbage, RPSORT (multiple
keys!) took just over 10 minutes in an NT Dos box,  NTs SORT (single key):
zapped it after more than 30 minutes... Both were running as the only real
process.

Robert
--
Robert AH Prins
prinsra@williscorroon.com

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    
Technical Details
Message-ID: <7f4grb$7ik$1@nnrp1.dejanews.com>
Path: arc1-ca.pugleaf.net!unknown!not-for-mail

Show Full Headers
Complete Article Headers
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 111659,e7de494902ed891c,start
X-Google-Attributes: gid111659,public
X-Google-Thread: 108ebd,e7de494902ed891c,start
X-Google-Attributes: gid108ebd,public
From: Robert AH Prins <prinsra@williscorroon.com>
Subject: Sorting - Big files
Date: 1999/04/15
Message-ID: <7f4grb$7ik$1@nnrp1.dejanews.com>
X-Deja-AN: 466662933
X-Http-Proxy: 1.0 x17.dejanews.com:80 (Squid/1.1.22) for client 193.130.234.1
Organization: Deja News - The Leader in Internet Discussion
X-Article-Creation-Date: Thu Apr 15 10:59:58 1999 GMT
Newsgroups: comp.lang.pascal.borland,borland.public.turbopascal
X-Http-User-Agent: Mozilla/4.05 [en] (WinNT; I)