Qiita APIでユーザに結びつくCoraboration数を持ってこれなかったので、自前でユーティリティを作り、さぁ、ランキングの出力を実装しようとした時のお話です。

取得結果をユーザ名とCoraboration数の辞書で返却しており、Coraboration数も文字として扱ってしまっていたため、組み込み関数のsortedで期待する動きをしてもらえません。

sort.py

import GetQiitaContribution

d = GetQiitaContribution.getContributionByFile("account.txt")

for v in sorted(d.values()):
    print  (v)

python3 ./sort.py
0
142
23
235
309
4
42

ここで、Python勉強中なので、いろいろ試してみました。

まずは、ユーティリティを修正する

辞書のvalueとして、素直にContribution数を数値として格納するように修正し期待通りのソートが実行されるようにしてみました。

#            dict[username] = getContributionByName(username)
            dict[username] = int(getContributionByName(username))

time python3 ./sort.py
0
4
23
42
142
235
309

real	0m4.177s
user	0m0.101s
sys	0m0.026s

real	0m3.636s
user	0m0.111s
sys	0m0.028s

real	0m3.377s
user	0m0.108s
sys	0m0.029s

ここで、もとの文字列格納バージョンと実行にかかる時間を比較してみました。

time python3 ./sort.py
0
142
23
235
309
4
42

real	0m4.298s
user	0m0.115s
sys	0m0.045s

real	0m3.535s
user	0m0.100s
sys	0m0.025s

real	0m3.606s
user	0m0.100s
sys	0m0.025s

Pythonにおける数値のソートと文字列のソートの速度差が気になる

文字のソートと数値のソートでどれくらい速度差がでるのか気になって比較してみたのですが、ソートだけを切り出した速度比較ではない(プロファイリングしていないのでなんともいえませんが、処理にかかる時間の大半はユーティリティで実施しているスクレイピングに費やされていると思われる)のと、ソートしているデータ数が大したボリュームではないというのもあり、参考になりません。

そこで本格的に比較してみることにしました。１から1048576(Excel for Macの最大行数)までの数値のリストと文字列のリストを作成し、それぞれをソートしてみました。

数値

real	0m12.400s
user	0m9.455s
sys	0m2.412s

real	0m12.522s
user	0m9.444s
sys	0m2.493s

real	0m12.500s
user	0m9.718s
sys	0m2.288s

文字列

real	0m14.583s
user	0m9.772s
sys	0m3.828s

real	0m12.000s
user	0m9.259s
sys	0m2.200s

real	0m12.183s
user	0m9.430s
sys	0m2.249s

どうやら、要素数が100万個程度では数値と文字列のソートにそれほど速度差はないようです。

結論

7桁オーダー程度では、文字列だろうと数値だろうと速度が出ないらしいです。LLが普及して随分立ちますが、ハードの進化なのかLLの進化なのか、ロートルなプログラマになりつつある自分は少しびっくりしながら、締りのないい記事はここでおわりにしたいと思います。

長々と駄文ここまで読んでくださった方、ありがとうございます。