追記: sort を使うときは，LC_ALL=C を忘れずに - ny23の日記

> wc --lines unigram_raw.txt 290768333 unigram_raw.txtそもそも，たかだか3億要素，1.7Gのデータのソートに，最近のマシンで sort | uniq -c が858分もかかるのは変ですよね． > export LC_ALL=C > time sort -S 2G unigram_raw.txt | uniq -c > tmp.sort.uniq sort -S 2G unigram_raw.txt 389.93s user 16.32s system 99% cpu 6:49.61 total uniq -c > tmp.sort.uniq 15.40s user 1.56s system 4% cpu 6:49.62 totalIntel Xeon E5462 (3.2Ghz) が Dual Core AMD Opteron 1210

[stealthinu]

sort使う時LC_ALL=Cにすると速度が100倍も違うという話。

[takuya-a]

LC_ALL=C だと sort はバイト順

[ono_matope]

明日活かせる豆知識だ

[C_L]

正確にはLC_COLLATEなんだけどLC_hogehogeシリーズいちいち覚えてられないから全部決め打ちっていうときに使うやつがLC_ALLなんでコンソールで打つ時はLC_ALLでOK

[chezou]

まさにこれだ！！！ “ LC_ALL=C sort -S 2G unigram_raw.txt | LC_ALL=C uniq -c > tmp.sort.uniq.utf8"

[pcod]

なんかsort遅いなと思ったらこれだった

[terazzo]

ロケールによって数値の桁区切り系の挙動を変えてるんだよね。(sort -nの結果が、LANG=ja_JP.eucJPだと200000<1,300,000、LANG=Cだと1,300,000<200000)／そういうの使わないならLANG=Cで良いと思うけど。