Qiita APIでユーザに結びつくCoraboration数を持ってこれなかったので、自前でユーティリティを作り、さぁ、ランキングの出力を実装しようとした時のお話です。
取得結果をユーザ名とCoraboration数の辞書で返却しており、Coraboration数も文字として扱ってしまっていたため、組み込み関数のsortedで期待する動きをしてもらえません。
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における数値のソートと文字列のソートの速度差が気になる
文字のソートと数値のソートでどれくらい速度差がでるのか気になって比較してみたのですが、ソートだけを切り出した速度比較ではない(プロファイリングしていないのでなんともいえませんが、処理にかかる時間の大半はユーティリティで実施しているスクレイピングに費やされていると思われる)のと、ソートしているデータ数が大したボリュームではないというのもあり、参考になりません。
そこで本格的に比較してみることにしました。1から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の進化なのか、ロートルなプログラマになりつつある自分は少しびっくりしながら、締りのないい記事はここでおわりにしたいと思います。
長々と駄文ここまで読んでくださった方、ありがとうございます。