in reply to Re^2: Sort big text file - byte offset - 50% there (Added code)
in thread Sort big text file - byte offset - 50% there
The sort should be on the unpacked epoch value.
No. A big advantage is that your packed binary epock dates should sort perfectly well without being unpacked provided that you use an alphasort (eg. cmp) and not numeric (<=>). And they will sort faster. This is the basis of the Guttman-Rosman Transform (GRT) sort.
To convince you of this, look at the binary representation of the following "epochs". Remembering that I am running on a little-endian machine so the byte ordering is reversed, each (numerically) bigger number is represented by a alphanumerically larger string when packed.
Update: Tye's right, you need 'N' not 'V'
[0] Perl> print unpack 'H*', pack 'N', 0+"1e$_" for 0 .. 10;; 00000001 0000000a 00000064 000003e8 00002710 000186a0 000f4240 00989680 05f5e100 3b9aca00 ffffffff
So, using the default sort on packed integers works fine provided that you use the correct pack format to match your platform's endianness. The bonus is, that this is the fastest sort, and by appending the offsets, any equal epochs will be sorted into file order. Try it.
|
|---|
| Replies are listed 'Best First'. | |
|---|---|
|
Re^4: Sort big text file - byte offset - 50% there (Added code)
by msalerno (Beadle) on Aug 14, 2006 at 15:13 UTC | |
by BrowserUk (Patriarch) on Aug 14, 2006 at 15:32 UTC | |
by msalerno (Beadle) on Aug 14, 2006 at 16:03 UTC | |
by BrowserUk (Patriarch) on Aug 14, 2006 at 20:22 UTC | |
by msalerno (Beadle) on Aug 14, 2006 at 21:13 UTC | |
|