Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                

Pretty Print 3

カバレッジが100%になるようにテストを書いたらfillにバグがあることに気づいた。xsとzsを間違えて無限ループになってた。名前ひどい。

色々変数名の変更とかリファクタリングを実行。テストが100%だと安心だ。テスト重要。

そしてようやくAUTOASTの作るS式をきれいに表示する方に着手。しかしpretty printが必要な規模だと数秒掛かる。あー、そうか、元のコードはHaskellだからか。遅延評価で書かないといけないな。逐語訳中にはリストや文字列の結合が遅いのではないかと思ってコメントにそう書いていたが、そんなもの以上の問題があったわけだ。

0 1 2 3 4
5 6 7 8 9
10 11 12
13 14 15
16 17

real	0m4.189s

高速化をするときにはまずプロファイリングをしないといけない。

http://gist.github.com/553325

ふむ。なんかものすごい階数呼ばれている関数が幾つかあるなぁ。でもその中で一番時間を食っているのはbeか。beがなんでそんなにたくさん呼ばれるのかを考える。

    if isinstance(y, Union):
        return better(width, already, 
                      be(width, already, [(i, y.x)] + tail),
                      be(width, already, [(i, y.y)] + tail))

犯人はお前か!!

遅延評価させた: http://gist.github.com/553321

おお、5秒かかっていたのが1ミリ秒くらいになった!めでたしめでたし!


ところでもっと大きな構造について試してみたら再帰呼び出し回数の上限オーバーで死んでしまった。まあ、末尾呼出の最適化をする言語のコードを移植したらそりゃそうなるわな。beの大部分のコードがreturn be(...)なので、これはループに変換されるべきってこったな。明日時間があればそれをやろう。