Pythonプログラムのパフォーマンスを改善したい、なんていうときに実行時間計測が役に立つだろう。ただし、本当にパフォーマンスを改善を図るのであれば、ボトルネックがどこにあるか、等を見つけて改善して行く必要があるのはもちろんである。

まぁ、そう出なくてもカリカリチューンしたい時なんかには、とにかく関数の実行速度を高速化したりすることもあるでしょう。

そんな時に利用可能な方法がないかどうか調べてみた。

timeitモジュールというのがあるらしい。timeitモジュールでは、Timerクラスというクラスが定義されている。これを使って関数の実行時間を計測することが可能。マニュアルを見ながらやってみる。

Timerクラスは、コンストラクタの引数として、計測対象となる処理、その計測対象処理を実行する前の初期化に必要な文、それから計測に使用するタイマー関数を引き渡すことができる。このクラスはtimeitモジュールに定義されているので、timeitモジュールをimport。

>>> import timeit

この後、Timerクラスのインスタンスを生成する。

>>> t = timeit.Timer(stmt="i=i+1", setup="i=0")

ここでは、stmt、つまり、処理内容を”i=i+1″、setupに”i=0″を引き渡している。これを実行するには、Timerクラスのrepeatメソッドを呼び出す。処理としてはまったく意味のないものを引き渡しているのだが、それは後で説明する。

>>> t.repeat()
t.repeat()
[0.06441807746887207, 0.06064486503601074, 0.0607151985168457]

そうするとこんなのが出てくる。repeatメソッドには特に引数を渡していないので実行条件はデフォルトのまま。渡された処理を100万回実行してその時間を3回計測する。その結果が表示されている。ここでは最速値が0.06064486503601074秒である。

Timerクラスのインスタンスを生成する際に”i=i+1″というあまり意味のない処理を引き渡したのは合計300万回実行されるからである。これ、テスト目的なので、print文とかを実行すると300万行出力されてしまうので、意味のない処理を引き渡した。

実際にはある関数を計測したいケースが多いと思う。この書き方がマニュアルの一番下の方に書かれている。参考にして同じようなコードを書いてみる。

00: import timeit
01:
02: def time_test():
03:     i = 0
04:     for i in range(100):
05:         i = i + 1
06:     print i
07:
08: if __name__=="__main__":
09:     t = timeit.Timer(stmt="time_test()", setup="from __main__ import time_test")
10:     print t.timeit(100)

ここでポイントになるのはTimerクラスのインスタンスを生成している9行目。
引数stmtに作成した関数time_test()を引き渡している。引数setupには、fromを引き渡している。これ、Timerクラスをインスタンス化するときにtime_test()関数がTimerクラスから見えないためにfrom-importして見えるようにする必要があるため。これを書いておかないと

NameError: global name ‘time_test’ is not defined

というエラーになってしまう。

その後、10行めでtimeit()メソッドを呼び出している。timeit()メソッドは、stmtを100万回実行してその実行時間を出力する。100万回はデフォルトだが、ここはテストなので100回を指定している。

マニュアルによると、ここで使用したtimeitメソッドは前からあるようだが、repeatメソッドはPython 2.6かららしいので、Python 2.5とかを利用している場合は使えなさそうだ。repeatメソッドはこの100万回実行に必要な時間を3回測ってくれるので使い勝手がいい。

あとはタイマーの精度だが、これはマニュアルによるとOSのタイマー関数の精度によったりするようだ(そりゃそうだろうとは思う)。良く使われるのはWindows,MacOS,Linuxだと思う。この記事を書くのに使ったのはMac OS Xなので悪しからず。

ところが、どうもおかしいんですよね。

システム環境設定から、プリントとスキャンを選択して+ボタンを押してプリンタを追加。Bonjourだしあまり苦労はない。簡単に追加自体は完了した。

ところが、どうもおかしい。2in1印刷の設定とかができない。仕方ないので、とりあえず印刷して用事には間に合わせたのだが、どうもおかしい。

仕方ないので、Epson社のサイトからドライバーをダウンロードしてインストールしてみた。このサイトからプリンタードライバーアップデーターというのをダウンロードしてインストール。

でもまだ直らない。

仕方ないので、システム環境設定のプリントとスキャンから一回プリンタを削除して再度登録。これで設定が可能になったようだ。Lionの標準ドライバだと設定できないのかもしれない。とりあえずこれで以前同様使えるようになったので良しとしよう。

非常にインストールは簡単だった。App Storeを起動して、インストールするだけ。

インストールした後は、アプリケーションフォルダにインストールしてあるのでこれを起動する。もちろんLaunchPadからも起動が可能。

起動するとライセンス許諾画面が出るので、ライセンスを読んでOKであればAgreeボタンを押す。そうすると、また何やらインストールが開始される。これが終わると、Start Using Xcodeというボタンが出てくるので、Xcodeを使えるようになる。ただし、どうもコマンドラインツールが単純には使えないみたいだ。

以前のバージョンのXcodeだと、Developerってフォルダにインストースされたと思うんだが、このバージョンだと”/Applications/Xcode.app”フォルダにみんな入っている。gccとかのツールも”/Applications/Xcode.app/Contents/Developer/usr/bin”に入っているようだ。試しに実行してみると実行できるみたいだが、ここにパスを通すのもなぁ。

と調べてみると、Xcodeを起動して、メニューのXcode->Preferences->DownloadsからCommand Line Toolsってのをインストールできるみたい。やってみると確かにインストールできて、gccとか使えるようになった。他にも、iOS 5.0 Simulatorとかここからインストールできるみたいだが、とりあえずこれでよし。

今まで何度か使ってきたjoin()だが、スレッドの終了を待つ場合などに使用される。あるスレッドが終了するまで、他のスレッドが実行を待つ場合などに使われる関数だ。

join()は、そのjoin()メソッドが属するオブジェクトのスレッドの実行が終わるまで終了しない。
このjoin()は、各スレッドオブジェクトのメソッドで、あるスレッドのjoin()を呼び出すとそのスレッドが終了するまで帰ってこないから、結果的にjoin()を呼び出した場合、その呼び出したjoin()が属しているスレッドが終了するまで呼び出し元は何もしない(というかjoin()が終了しないからできない)ことになる。

試しに下記のコードを書いてみた。今回、行番号とコメントも入れてみた。

01: import time
02: import threading
03:
04: class threadTest(threading.Thread):
05:     def __init__(self,idx):  # 引数 idx を受け取る
06:         threading.Thread.__init__(self)
07:         self.i = idx         # 引数を i に保存
08:
09:     def run(self):
10:         print "Thread start. %d\n" % self.i # 引数を表示
11:         time.sleep(5)                       # 5 秒間スリープ
12:
13: pt1 = threadTest(1) # スレッドを区別するため数字の 1 を渡す
14: pt2 = threadTest(2) # スレッドを区別するため数字の 2 を渡す
15:
16: pt1.start() # 一つ目のスレッドスタート
17: pt1.join()  # 一つ目のスレッドに join() する
18: pt2.start() # この行は一つ目のスレッドの join() が終了するまで実行されない
19: pt2.join()  # 二つ目のスレッドに join()

これを実行すると、単に”Thread start. 1″に続いて”Thread start. 2″が表示されるだけだが、”Thread start. 1″の後、5秒間待ってから、”Thread start. 2″が表示される。

スレッドクラスの定義は04行目から11行目まで。引数を一つ取り、それを表示した後、5秒間スリープするだけの関数を実行する。13, 14 行目で一つずつスレッドクラスのオブジェクトを生成。
生成した一つ目のオブジェクトのスレッドを実行しているのが16行目である。この一つ目のスレッドのjoin()を17行目で呼び出している。この17行目のjoin()は、一つ目のスレッドが終了するまで終了しない。そのため、呼び出し側も約5秒間待つことになる。

そして5秒間待った後、ようやく二つ目のスレッドが実行されることになる。これが18行目。19行目でjoin()しているのでメインスレッドも二つ目のスレッドが終了するまで待ってから終了する。このようにjoin()を使うとあるスレッドの終了を待ってから別の処理に移ることが可能になる。

このjoin()便利なんだが、気をつけなければならないこともあって、複雑なプログラムを作成するときには、join()の呼び合いにならないようにする必要がある。例えば以下のコードはわざと呼び合うようにしたもの。

01: import time
02: import threading
03:
04: class threadTest(threading.Thread):
05:     def __init__(self,idx):  # 引数 idx を受け取る
06:         threading.Thread.__init__(self)
07:         self.i = idx         # 引数を i に保存
08:
09:     def run(self):
10:         time.sleep(5)                     # 5 秒間スリープ
11:         print "Thread start. %d\n" % self.i # 引数を表示
12:         if self.i==1:
13:             pt2.join() # i==1 ならば pt2 に join()
14:         else:
15:             pt1.join() # そうでなければ pt1 にjoin()
16:         time.sleep(5)                     # 5 秒間スリープ
17:
18: pt1 = threadTest(1) # スレッドを区別するため数字の 1 を渡す
19: pt2 = threadTest(2) # スレッドを区別するため数字の 2 を渡す
20:
21: pt1.start() # 一つ目のスレッドスタート
22: pt2.start() # 二つ目のスレッドスタート
23: pt2.join()  # 二つ目のスレッドに join()

こちらのスレッドクラスでは、12-15行目で引数に従って他のスレッドにjoin()するようにしてある。18,19行目でスレッドクラスのオブジェクトを作成しているところは変えていないので、pt1はpt2に、pt2はpt1にjoin()することになる。10行目にsleep(5)を入れているのは、pt1がpt2にjoin()するのが早すぎるとpt2が走り出す前にjoin()しようとしてエラーになるためだ。

こういう風にしておくと、スレッドがお互いにjoin()しあってしまうので、このプログラム、永久に終了しない。お互いのスレッドがお互いが終了するのを待ち合うためである。いわゆるデッドロック状態に陥ってしまう。スレッドのjoin()を使う時はこういう状態を作り出さないように注意する必要がある。

Time Capusleと合わせて使うと勝手にインクリメンタルバックアップしてくれて、パーソナルユースでは十分なバックアップソリューションになる。

そのTime Machineなんだが、LionにしてからTime Machineに入ると紫っぽいバックアップと白いバックアップの二通りがある。これは一体なんなんだろう。マニュアルを読んでみるしかないかな・・・。

調べてみると、紫色のやつは、Local snapshotsというやつらしい。Time Machineのバックアップ先に接続できない状況のときにローカルディスク上にスナップショットを作成するという機能があって、それで作成されたものが紫色になる。
このローカルに作成されたスナップショットはTime Machineのバックアップ先に接続できるようになると、そのバックアップ先のディスクに書き込まれるとか。

この機能、持ち歩かれることの多いMacBookのユーザーには便利かもしれない。MacBook Airなんて持ち歩いてこそのMacBook Airだと思うし。でも、ローカルディスク上にバックアップってことは、それ、ローカルのHDDがクラッシュしたら結局なくなるし(だからバックアップ先がオンラインになるとそっちに書き出すのだろう)私にはあんまり意味はないかもしれない。移動中に間違ってファイル消してしまってそれを復活させたい、なんて時には役に立ちそうだが、それ以外のケースではどうかなぁ・・・。逆にSSDによけいな書き込みをして欲しくないなぁ、とも思ったりする。

というわけで、この機能を止めたい。

とは言っても、システム環境設定中のTime Machineを確認しても、そういう設定項目は見当たらない。止められないのかと思いつつ、手当たり次第情報を当たってみると、ある書籍にtmutilというコマンドが存在すると書かれていた。詳細は、manを見ろと。

MacOSでmanを見ることも今まであまりなかった。UNIX系OSでは標準的に使われるオンラインマニュアルを表示するコマンドがman。MacOS Xにももちろん存在するようなので、manを引いてみる。アプリケーションのユーティリティの中からコンソールを起動して、man tmutilとタイプしてリターン。manの使い方まではここには書かないが、別に他のUNIX系OSと変わるところはあまりない。

表示されたオンラインマニュアルを読んでみると、enablelocalとdisablelocalオプションでこのローカルスナップショットの有効/無効化ができるらしい。マニュアルにはRequires root privilegesって書いてあるから、rootユーザーでないとじっこうできないようだ。さらに、disablelocalの方はローカルスナップショットをクリーンアップすると書かれている。ということで早速実行してみる。root権限が必要らしいので、

# sudo tmutil disablelocal

をコンソールで実行。root権限が必要なコマンドなのでパスワードを聞かれる。適宜入力してリターンキーを押下。

を？なにやら画面右上にあるTime Machineのアイコンが回り始めた。試しにクリックして何をしているのか見てみると、バックアップ作成中、と表示された後、数十MBだの数十KBだの何度か異なるサイズのバックアップを作成しているようだ。そして最後に、クリーンアップ中、と表示され、処理が完了した。

これは偶然Time Machineがバックアップを作り始めたのか、それともローカルスナップショットの書き出しを行ったのか・・・。クリーンアップが終わったらディスクの使用領域が減っていたので、クリーンアップしたんだろうな、きっと。

このtmutil、他にも色々できて、バックアップ一覧を閲覧したり、削除したりも可能。バックアップの一覧を見るには、“tmutil listdisks”“tmutil listbackups”コマンド、削除をするにはroot権限が必要なので、sudoを付けて、”sudo tmutil delete バックアップディレクトリ”とする。バックアップディレクトリのパスにスペースが含まれていると正しく動かないみたいなので、その場合には、パスを”"(ダブルクォーテーション)で囲めばいい。

これ、便利そうだな・・・。Apple Scriptとかでバックアップ削除をTime Machineに入らなくても出来るようにしたり出来たりするんだろうか。bashスクリプトかなにかで書いてやれば十分な気もするが。

ちょっと方法を調べるのに手間取ったが、MacOS XのUNIXな一面を見られたので楽しかった。やはりまだまだ奥が深そうだ。

今回は実際に生成されるスレッド数をあんまり正確ではないが確認してみる。

実際に生成されるスレッド数と言っているのは、Pythonのスレッドを作成すると生成されるOSのスレッド数のことである。PythonスレッドがいくつになるかはPython側で作成した個数になるに決まっている(というか決まっていてくれないと困る)のだが、OS側のスレッドはいくつ作成されるのかということ。

例えば100本Pythonスレッドを生成したとすると、OS側のスレッドは何本生成されるのか。
なぜそんなことを調べたいというかという、実装次第ではOS側スレッドは一つでもいいはずだからである。どうするかというと、自前スレッドを作ればいい。OSスレッドは一つで、そのスレッドをそれぞれのPythonスレッドに対して切り替えて使う。ファイバーに近い形になるか。
Pythonはそんな実装にはなっていないと思うが、もしそんな実装になっているとすると、昨今のマルチコアCPUを十分に生かせないことになる。さっきも書いた通り、そんな作りにはなってないと思うのだが、念のため、適当なやり方ではあるが、確認してみる。

まず、以下のように100個Pythonスレッドを生成して、最後に生成したスレッドにjoin()して、生成したスレッドは、単純に無限ループするコードを書く。こうすると、100個のスレッドとメインスレッドがいつまでも終了しないプログラムになる。

import threading
import time

class threadNotFinish(threading.Thread):
    def run(self):
        while True:
            print "Thread is sleeping ..."

i = 0
while i<100:
    th = threadNotFinish()
    th.start()
    i = i + 1
print "All thread were created."
th.join()

これ、実際に実行するときには注意が必要。何しろスレッド100本走りっぱなしである。メモリこそ喰わないだろうが、気をつけておく必要がある。

実際スレッド数を数えるのに使うのはtopコマンド。別に正確に計測する必要もないので、topコマンドを眺めていればいいだろう。topコマンドを使うにはコンソールを起動する必要がある。コンソールは、MacOS Xだと、アプリケーションのユーティリティの中にあるのでクリックして起動。起動したら、topと打ち込んでリターンキーを押す。以下のような内容が表示される。

Processes: 91 total, 3 running, 6 stuck, 82 sleeping, 399 threads      02:40:40
Load Avg: 0.66, 0.43, 0.37  CPU usage: 4.36% user, 8.0% sys, 87.62% idle
SharedLibs: 1176K resident, 0B data, 0B linkedit.
MemRegions: 11216 total, 1278M resident, 42M private, 295M shared.
PhysMem: 908M wired, 1678M active, 1497M inactive, 4083M used, 10M free.
VM: 223G vsize, 1092M framework vsize, 120741(359) pageins, 190(0) pageouts.
Networks: packets: 470443/331M in, 605050/511M out.
Disks: 575982/8992M read, 498237/9301M written.

PID  COMMAND      %CPU      TIME     #TH  #WQ  #POR #MREG RPRVT  RSHRD  RSIZE
907  CVMCompiler  7.5       00:00.22 1    0    30-  72+   6868K+ 520K-  13M+
898  diskimages-h 2.3       00:00.76 4    2    64   73    1580K  5996K  7956K
890  hdiejectd    0.0       00:00.03 2    1    36   47    608K   256K   1908K
884  backupd-help 0.0       00:00.01 2    1    43   43    676K   220K   1992K
883  xpchelper    0.0       00:00.02 2    2    37   48    928K   220K   4480K
882  distnoted    0.0       00:00.00 2    1    40   52    528K   240K   1208K
881  mdworker     0.0       00:00.24 3    1    50   77    1724K  8060K  5916K
(以下略)

これはMac OS Xでの出力。他のOSだと出力形式が違うかもしれない(というか違う)。ここでは、topコマンドの内容全部の説明はしない。これを実行させっぱなしにしておいて、一番上の行中にある
Processesとthreadsの数字を注視しておく。上の例では91プロセスの399スレッドである。ここを注視しておいて、さっき作ったスレッドをたくさん生成するPythonコードを実行する。

スレッドが無限ループしていて、ずっと同じ文字が出力され続けるだけなので、出力は特に示さないが、ずっと実行され続けている。そこで、Processesとthreadsの数字を実行前後で比較してみる。

Processes: 74 total, 2 running, 1 stuck, 71 sleeping, 315 threads      02:50:17
Load Avg: 0.66, 0.77, 0.57  CPU usage: 2.18% user, 2.42% sys, 95.38% idle
SharedLibs: 1176K resident, 0B data, 0B linkedit.
MemRegions: 10164 total, 1243M resident, 36M private, 263M shared.
PhysMem: 908M wired, 1635M active, 1289M inactive, 3832M used, 263M free.
VM: 183G vsize, 1092M framework vsize, 124684(0) pageins, 2318(0) pageouts.
Networks: packets: 619961/392M in, 952989/950M out.
Disks: 578833/9325M read, 499039/9305M written.

PID  COMMAND      %CPU TIME     #TH  #WQ  #POR #MREG RPRVT  RSHRD  RSIZE  VPRVT
944  top          3.1  00:00.70 1/1  0    28   32    792K   328K   1508K  17M
936  bash         0.0  00:00.00 1    0    20   23    376K   840K   1132K  17M
935  login        0.0  00:00.01 2    1    33   66    880K   372K   2140K  50M
932  bash         0.0  00:00.01 1    0    20   23    388K   840K   1164K  17M
(以下略)

これが実行前。次が実行後である。

Processes: 75 total, 4 running, 1 stuck, 70 sleeping, 439 threads      02:50:45
Load Avg: 1.32, 0.90, 0.62  CPU usage: 38.62% user, 50.94% sys, 10.42% idle
SharedLibs: 1176K resident, 0B data, 0B linkedit.
MemRegions: 10568 total, 1257M resident, 37M private, 266M shared.
PhysMem: 909M wired, 1654M active, 1291M inactive, 3854M used, 240M free.
VM: 186G vsize, 1092M framework vsize, 125508(0) pageins, 2318(0) pageouts.
Networks: packets: 620046/392M in, 953071/950M out.
Disks: 579001/9331M read, 499462/9315M written.

PID  COMMAND      %CPU  TIME     #TH     #WQ  #POR #MREG RPRVT  RSHRD  RSIZE
945  Python       163.4 00:16.19 101/6   0    123  268   5132K  328K   6608K
944  top          4.8   00:01.75 1/1     0    29   32    800K   328K   1516K
936  bash         0.0   00:00.00 1       0    20   23    376K   840K   1132K
935  login        0.0   00:00.01 2       1    33   66    880K   372K   2140K
o(以下略)

実行前が74プロセス、315スレッドに対して、実行後は75プロセスの439スレッド。スレッド数がちょっと増え過ぎだが、100以上増加はしている。100以上増加したのはなぜだと聞かれると分からないのだが、システム全体でそれだけ増加しているのだろう。実際、単にtopコマンドだけ実行して眺めていると、結構threads数は上下する。
ただし、ここで問題にしているのは、正確な増加数ではないので気にしない。重要なのは、1プロセス増加、つまり、実行したPythonプロセスの分だけプロセスが増加し、スレッドを100個作ってもプロセス数は増加しなかったこと、その分スレッドが増加したことである。

そういうわけで、Pythonのスレッドを作成すると、OSのスレッドを生成しているであろうことが分かった。これならば、マルチスレッド化すれば、ハイパースレッディングやらマルチコアやらの恩恵を受けられるであろう。きっちり調べるには、Pythonのソースコード(誰かがPythonで書いたコードではなくて、Pythonそのもののコード)を確認すればいいのだろうが、さすがにそれは面倒なのでやらない。

今書いているコードもマルチスレッド化してみようかな。

わざわざSnow Leopardを入れ直すこともないので、そのまま使っているのだが、キーボードのバックライトが気になって。

このキーボードのバックライト、たった一度だけ役に立ったことがある。私はMacBook Airを会社での仕事に使っているわけではないので、これを使ってプレゼンテーションとかをすることはなかったし、多分これから先も、残念ながらないだろう。上司にMacBook Air使いたいから買ってくれと言ったらすんなり却下されてしまったこともあるし、こればっかりはどうしようもない。

このキーボードのバックライトって、プレゼン会場とかであたりが薄暗い中キーボードが見えない時に使うもんだと思うのだが、一度だけ、薄暗い移動時の車中で使わざるをえなくなったことがあり、そのときには重宝した。普段使わないのでどうでもいい機能だと思っていたりするものが、実際使ってみると非常に便利だってのは実はよくあることなのかもしれない。その時も、薄暗い車内でタイプするのに非常に役に立ってくれた。

とは言え。

普段はまず間違いなく使わないので、私にとっては、ほとんどの場面で単なる電池喰いでしかない。
今も移動中にMacBook Airでこれを書いているのだが、あたりは普通に明るい。電車の車内だからまぁ当たり前だ。日本の電車内なので、本を読んでいる人も多いわけで、キーボードのバックライトなんかなくても全然困らない。

それで、このキーボードバックライト、OFFにしたかったのだが、システム環境設定中にはそんな設定項目なかった。確かSnow Leopardの時にはキーボードバックライトのスイッチを切る、という設定があったと思うのだが、探してみても見当たらない。

前置きが長くなったが、これ、F5キーとF6キーで輝度を変更するようになったようだ。F5を押しっぱなしにしていると、2,3秒かけて段々と暗くなっていき、そのうち真っ暗になって消える。F6を押すと、一回押す毎に一段階ずつ明るくなっていく。押しっぱなしにしておくと、F5キーで暗くした時のように、2,3秒で最大輝度になる(実はF5キーも一回押すごとに一段階ずつ暗くなる)。

これでキーボードバックライトを消すことが出来た。これについては、別に一段階ずつ調節できなくてもいいんじゃないか??と思わなくもない。ON/OFFのトグルで、ONになったときには自動調整でもいい気がするのだが、まぁこれで消せる。

別にキー一発でON/OFFなんてそもそもいらないんじゃない？という話もあるのだが、実際さっき書いた車中で使ったときには、えーと、ONにする設定ってどこだっけ？としばらく探してしまったことを思い出した。何しろそうめったにON/OFFしないので設定項目がどこにあるのだか覚えていなかったのである。

というわけで、多分キー押しただけでなので、単にON/OFFするだけのキーを付けて、限りあるキーを他の用途に使う、ってのが一番良かったんじゃないかなぁ。私の場合、ほとんど使わない機能なのでそう思うだけなのか・・・

ということで前置きが長くなったが、キーボードのバックライトはF5,F6キーで調節、On/Offできるようですな。

今回は前回と異なり、threading.Threadクラスのサブクラスは作成しないでスレッドを作成、スレッドに引数を渡してみる。

まず単にスレッドを生成するコードを書いてみる。前回までは、threding.Threadクラスを継承したサブクラスを作成していたが、今回は、直接threading.Threadクラスのインスタンスを生成する。

import threading

def thread_function():
    print "Thread start"

i = 0
while i<10:
    th = threading.Thread(target=thread_function)
    th.run()
    i = i + 1
print "All thread were created."

threading.Threadクラスのインスタンスを直接生成する場合には、スレッド実行する関数を定義して、それを引数targetとして引き渡す。上の例では、スレッド実行する関数としてthread_function()を定義している。これをthreading.Threadクラスのコンストラクタにtarget引数としてその関数名を引き渡して、インスタンスを生成している。

インスタンスを生成したら、そのインスタンスのrun()メソッドを実行するとスレッドが実行される。

このコードを少し書き換えて、引数を渡せるようにしてみたのが以下のコード。

import threading

def thread_function(idx):
    print "Thread start %d" % idx

i = 0
while i<10:
    th = threading.Thread(target=thread_function,args=(i,))
    th.run()
    i = i + 1
print "All thread were created."

こんな感じになる。まず、スレッド実行する関数thread_function()に引数の宣言を追加する。

def thread_function(idx)

threading.Threadクラスのコンストラクタを呼び出す方には、最初の例ではtargetだけだったが、args引数として、スレッド実行する関数に渡す引数を指定する。ここで渡すのはタプルなので注意。

th = threading.Thread(target=thread_function,args=(i,))

argsに渡すのはタプルなので、(i,)を引き渡していることに注意。iの後ろに,(カンマ)を付けている。これで単なる整数ではなくタプルを引き渡すことになる。

この引数がスレッドに渡されるときには、タプルではなくて、分割して引き渡される。なので、thread_function()側では単なる引数で受けることになる。上のコードを実行すると以下のようになる。

Thread start 0
Thread start 1
Thread start 2
Thread start 3
Thread start 4
Thread start 5
Thread start 6
Thread start 7
Thread start 8
Thread start 9
All thread were created.

ここで、thread_function()にさらに引数を追加してみる。

import threading

def thread_function(idx,idx2):
    print "Thread start %d, %d" % (idx, idx2)

i = 0
while i<10:
    th = threading.Thread(target=thread_function,args=(i,i+1))
    th.run()
    i = i + 1
print "All thread were created."

こんな感じになる。threading.Threadクラスのコンストラクタには、タプルで渡している。

    th = threading.Thread(target=thread_function,args=(i,i+1))

argsにはタプルで引数を渡す。一方、引数を受ける、targetで指定する関数の方は、普通の変数の並びになる。

def thread_function(idx,idx2):

実行結果は以下のようになる。

Thread start 0, 1
Thread start 1, 2
Thread start 2, 3
Thread start 3, 4
Thread start 4, 5
Thread start 5, 6
Thread start 6, 7
Thread start 7, 8
Thread start 8, 9
Thread start 9, 10
All thread were created.

こんな感じで、タプルの各要素がそれぞれの引数に渡される。

今までやってきたthreading.Threadクラスのサブクラスを使う方法とどっちがいいとか、どっちにはどんな利点があるとかまではまだ分からないのだが、このやり方でもスレッドを生成可能。どっちがいいんだろうね。次回もスレッドをやる予定。

前回書いた単にスレッドを生成するコードは以下のようになる。

import threading

class threadArg(threading.Thread):
    def run(self):
        print "Thread start."

i = 0
while i<10:
    th = threadArg()
    th.start()
    i = i + 1
print "All thread were created."

このコードはスレッドを10個生成する。それ以外には特に何もしない単純なプログラムである。
このコードをスレッドに引数を渡せるように書き換えてみる。

class threadArg(threading.Thread):
    def __init__(self,idx):
        threading.Thread.__init__(self)
        self.i = idx

    def run(self):
        print "Thread start. %d" % self.i

i = 0
while i<10:
    th = threadArg(i)
    th.start()
    i = i + 1
print "All thread were created."

こんな感じで書いてみた。実行すると以下のような出力が得られる。

Thread start. 0
Thread start. 1
Thread start. 2
Thread start. 3
Thread start. 4
Thread start. 5
Thread start. 6
Thread start. 7
Thread start. 8
Thread start. 9
 All thread were created.

このコードは、メインスレッドからthreading.Threadクラスを継承して作ったthreadArgクラスのコンストラクタに整数を引き渡し、スレッドとして実行されるthreadArgクラスのrun()メソッドでそれを表示している。動作としては相変わらず単純。

まず、threading.Threadクラスを継承したサブクラスを作成する時は、コンストラクタ__init__()と、run()メソッドしかオーバーライドしてはいけない、とマニュアルに記載されている。また、__init__()をオーバーライドした場合には、サブクラス側の__init__()の先頭でスーパークラスのコンストラクタを呼び出すようにする必要がある。

class threadArg(threading.Thread):
    def __init__(self,idx):
        threading.Thread.__init__(self)
        self.i = idx

    def run(self):
        print "Thread start. %d" % self.i

上の強調表示している部分がスーパークラスのコンストラクタを呼び出している部分である。その次の行で、self.i = idxとして、インスタンス変数のiに引数として渡されたidxを保存している。run()メソッドは単にself.iを表示しているだけである。

メインスレッド側では、合計10個のthradArgクラスのインスタンスを生成し、そのコンストラクタに0から9までの数字を渡して、最後にメッセージを表示するだけという、他にもう少し書き方はないのかと言われそうな感じのコードである。非常に単純な処理なのと、今回の本題ではないのでまぁ良かろう。

i = 0
while i<10:
    th = threadArg(i)
    th.start()
    i = i + 1
print "All thread were created."

こんな感じでthreading.Threadクラスのサブクラスを生成してスレッドを作成する際に引数を渡すことができた。実はここに至るまでに調査とか実験に結構時間がかかった。他にもっといい方法があるのかもしれないが、まぁできたのでとりあえず。
threading.Threadクラスのサブクラスを作らないでスレッドを作成する方が引数が渡しやすいのかもしれない。次回以降、それをやってみようと思う。

SSDの耐久性が大丈夫なんだろうか心配していたが、最近はあんまり気にすることもないと聞いたのと、キータッチがどうにも好きになれなかったので躊躇していたのだが、薄く、軽く(はあまりなっていないが)の方向に進んでいくなら、キータッチについては今後はあんまり変わらないかな、と思い始めたので、思い切って変えてみた次第。ついでにMacOSもLionになった。

結果、これは大分世界が変わる。電源を入れてから起動するまでの時間が早いこと早いこと。リッドを閉めてスリープ状態にしておいて、再度開いたときの復帰にかかる時間も本当に数秒そこそこ。あまり重量が軽くなった気はしないのだが、薄くはなっている気がする。そんなわけで携帯性はほとんど変化はないが、HDDがSSDなので、衝撃をあまり気にする必要がなくなった。これは大きい。HDDが動作している間は派手に動かしたくないので、今までのMacBook Airだと、リッドを閉じてからスリープするまではそっと扱っていたのだが、そんな必要もなくなったんである。リッドを閉じて鞄に放り込んでおけばいい。あとは勝手にスリープするだろう。

買ってから気がついたのだが、これは冷却ファンも付いてないのかな？今まで使っていたMacBook Airには通気用の穴が裏に開いていた気がするのだが、このMacBook Airには付いていない。動作音は異常に静かだ。

バッテリーの持ち時間も非常に長く、今確認すると残り9時間とか出ている。外出中に電池切れを心配する必要もほとんどなくなってしまった。

一番懸念していたキータッチだが、これはやはり浅くなった。会社で使っているのはThinkpadなのだが、あれと比べるとやはりどうしても浅め。HHK Pro2と比べたら雲泥の差なのだが、軽く叩くだけで入力できるのでむしろ入力速度は速くなった気がする。これはちょっと驚いた。これは使っていけそうである。最後に心配になるのは耐久性だが、私はそんなに強くキーを叩いてはいない(と自分では思っている)ので、多分大丈夫だろうと思うのだが、こればっかりは使ってみないと分からない。

これだけ世界が変わるならもう少し早く変えても良かったかもしれない。これは世界が変わる。使いたくなったときにその場ですぐに使える。

もう一つ驚いたのは、Spotlight検索でメールが検索にヒットした時に、Mailを起動していないときにクリックしてしまった時の動作である。それを表示するにはMailを起動する必要がある(勝手に起動される)のだが、この起動の速いこと速いこと。これはSSDの速度に寄与するところが大きいんだろうな。

これだけ世界が変わるなら早いところ乗り換えれば良かった・・・