追記: 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
LC_ALL環境変数とsortコマンド - sileのブログ
自分の環境では、sortコマンドを実行する時にLC_ALL環境変数に'C'をセットするかしないかで、処理終了までの時間が著しく変わる。 # 約40万行のデータ > wc -l words 392126 words # 入っているのはUTF-8の日本語(IPA辞書を利用) > head words やぼったい やぼったし やぼったから やぼったかろ やぼったかっ # 普通のソート > time sort words > /dev/null real 0m37.158s user 0m37.098s sys 0m0.056s # LC_ALL=Cでのソート > time LC_ALL=C sort words > /dev/null real 0m0.293s user 0m0.284s sys 0m0.008s ロケールを考慮してソートするかどうかの違いだと思うが(LC_ALL=Cの場合は、
RE: sort を使うときは，LC_ALL=C を忘れずに - ny23の日記
Twitter ID も livedoor ID もないので直接コメントできないが，sort (GNU coreutils) の名誉のために，ここにメモしておく． 404 Blog Not Found:algorithm - bucketsort.[ch] - 汎用かつlibcの*sortより高速な まず第一印象として，この程度のサイズのファイルのソートで sort (GNU coreutils) がいまどきこんなに遅いはずはない．LC_ALL=C で追試すると，やはり bucketsort との差は無くなった．上の記事（に対するツイート）は Twitter 上でもそれなりにリツイートされているように見えるのだけど，この実行時間に違和感を感じる人が全くいないのはどういうことなのだろうか．sort を実際に使う人がほとんど見ていないのか，それとも計算量が違うから速くて当然という思い込みか．
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
