> Carl: > > But they were in a very pretty order Andrew, which that would've stuffed > up. (; > > See? Ascending length per number.
Andrew: > I wonder if that's important to Louis? :) I think the answer is we don't know for sure, so this thread has developed into two parallel tracks, with a third on the way. TRACK 1 Has several of us looking at increasingly faster ways to pre-process the lines to get stable sort keys. The insights from that are most recently summarised by Joel's latest email. TRACK 2 Is looking at raw sorting speed: Andrew and Dick comparing hand-carved C with Rebol's 'sort. There are some interesting numbers coming out of that. It looks to me that Rebol's 'sort can hold its own against the hand-carved C. That's probably because, deep down inside, it is hand-carved C. But, as Joel points out, we can't just say faster or slower. We need to say what data we are using. Perhaps there'd be a completely different result if the lines were each 250 bytes long (or 250,000 bytes -- that'd be a stress test and a half). Or if there were 50,000,000 records. Or running on different platforms. A few people with C compilers joining in Andrew and Dick's language shoot out would add some more interesting numbers. (I can't help here -- the last time I used a C compiler it came on 5.25" floppies). TRACK 3 Is maybe just beginning to emerge: it's using the results from Track 1 to ask questions about memory management, or effects of running long-term. This is bound to be a tricky one to reach general conclusions on as it will be seriously platform, equipment, and version dependant. It might make sense start posting under new subject lines for the different topics. Sunanda. -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with "unsubscribe" in the subject, without the quotes.
