From: marcov@stack.nl   
      
   On 2004-10-01, Glenn Someone    
   wrote:   
      
   (mergesorting story trimmed)   
      
   > So if we do the math, we'll have 32 blocks of sorted data.  What now?   
   > We have to reconcile all these sorted blocks of data with one another.   
   > So we have to read them back in.  Do we nibble off the first record of   
   > each block and then sort that?  No, that'd be way too many I/Os off   
   > the bat.  So we read the blocks back in 2 at a time to merge them and   
   > reconcile each block.  So we're up to 512K of memory necessary.   
      
   Why do you merge only with two files? You can use as many as you have   
   guaranteed free file handles. (and read-bufferspace, but that isn't really a   
   problem, for 10 files 10*8kb or so)   
      
   Your story then still goes up, but is a lot less severe, since you can e.g.   
   reduce the amount of files in log10 times instead of log2.   
      
   > Basically put, the less amount of memory I have, the more disk I use.   
   > The more memory I have, the less disk I/O I use.   
   >   
   > Do you see the need now for more memory in this particular   
   > application?   
      
   With 64MB you can then still sort an awful lot of data in one pass (since   
   you can merge 10*64MB=640MB with writing the 640MB only twice, one temp,   
   one definite)   
      
   I would do that, with the buffer on 64MB, and let the user override that size   
   in configpanel/ini/cmdline.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)