in reply to Storing unordered data from file in memory

You can avoid sorting altogether. And you should.

As your records are fixed length, (barring the first and last?), there is a direct arithmetic relationship between the address of a record and its position in the file. So, use a big scalar--the most efficient form of Perl memory--and write records directly in-place. Or even directly to disk and avoid large memory usage.

As for tracking whether all the records have been written, the same arithmetic properties can be used to reduce the absence/presence of a given record, to a single bit in a bit-string. With 46-byte records, 200 MB reduces to a 1/2 MB bit-string for tracking. And this is easily and quickly checked for completion by a simple: 

if( $tracking =~ m[[^\0]] ) { 
     ##    ...
}

[download]

I know you are using threading. If the records of an individual file are being produced by different threads, then some care will need to be taken to ensure these large scalars are not replicate per thread. Perhaps the simplest way would be to use a Queue to a single writing and tracking thread.

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
RIP an inspiration; A true Folk's Guy

Replies are listed 'Best First'.
Re^2: Storing unordered data from file in memory
by Dirk80 (Pilgrim) on Jul 21, 2010 at 15:11 UTC

    In my example all S-Records have the same length. But this has not to be the case. Each S3-Record has a field which indicates the number of bytes for address, data and checksum.

    Can you explain me the tracking in more detail please. Because I do not understand your idea completely. You mean that I have a bit-string in memory. And I initialise it with 0 and if I find a record then I put a 1 at this position. At the end I have to check if all positions in the bit-string are set to 1. Is this correct?

[reply]
      But this has not to be the case.

      Unless all the records in a given file (or, at least in each given portion of a file; though that does complicate things considerably), then the idea doesn't work. But if they are, then it converts an O(n log n) process to O(n), which will have a far more profound effect upon your processing performance than specific sort implementations ever will.

      The fundamental requirement for this to work is a simple arithmetic calculation to convert the address of a record to its position in the file. I envisioned this being something like: 

      my $filePos = ( $recAddr - $firstRecAddr ) * ( $recLen + 1 ) + $lenOfH
+eader;

      [download]

      This would then allow you to seek directly to the appropriate file (or ramfile) position, and write the record in its final position directly. A similar calculation can be used to address the appropriate bit in the tracking bit-vector.

      You mean that I have a bit-string in memory. And I initialise it with 0 and if I find a record then I put a 1 at this position. At the end I have to check if all positions in the bit-string are set to 1. Is this correct?

      You have the general idea, but I inverted the state of the bits. Ie.

      I envisaged initialising the all the bits to 1: my $tracker = chr(255) x ( $noOfRecords / 8 );

      Then unsetting the bits as the records are written: vec( $tracking, 1, $recNo ) = 0;

      Then testing for completion by search the tracking vector for non-zero bytes: if( $tracking =~ m[[^\0]] ) {...

      But doing it the other way, initialising to 0, setting bits and then searching for non-0xff bytes is the same.

      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom