会社のBlogに書いた通り、現在新しい dict の実装を試しています。
また、 shared key を削除して実装を削れた分、別の効率のいい特殊化 dict を実装して、 compact + shared よりも高い効率を狙うこともできます。 今はあるアイデアのPOCを実装中なので、採用されたらまた紹介します。
と書いたのですが、とりあえず Python のテストは完走するようになりました。
Python-Dev に投稿したメール の通り、 Sphinx で Python の Doc を make html するのにかかるメモリ使用量は、 Python 3.6a2+ (Python 3.5 と同等の key sharing dict) では 176MB, 上の key sharing を外した新 dict 実装ブランチでは 160MB で、 key sharing を外しても十分に省メモリかできている事が判ります。
Python-Dev では、アプリケーションによってはほとんどの dict がインスタンスの __dict__ なんじゃないか、その場合は無視できないリグレッションになるのではないか、という意見がでていて、説得するためにリアルなOOPで書かれたアプリケーションにおけるメモリ使用量のデータをもっと集めたいところです。
そこで、興味があって計測に適したアプリケーションを用意できる人は interned-dict ブランチ を試してみていただけないでしょうか？
計測に適したアプリケーションは次のとおりです。
- OOPで書かれていて、かなりの数のインスタンスを作る
- Python 3.6a2 と上記のブランチの2つのプロセスで同じ状況を再現でき、その時のメモリ使用量を計測できる
- 繰り返して安定した結果を得られる
また、 Sphinx のビルドのように CPU バウンドで数分で実行できて実行時間が安定しているアプリケーションであれば、 /usr/bin/time を使って maxrss と同時に実行時間も計測していただけると助かります。 （その際、比較対照の 3.6a2 は同じ configure オプション、同じ環境でビルドしたものでおねがいします。）
計測結果は、
をつけて、
[Python-Dev] Idea: more compact, interned string key only dict for namespace.
に返信するか、上記のプルリクエストにコメントしてもらえれば私が転載します。
また、万が一クラッシュしてしまった場合も、上のプルリクエストに (再現可能なら faulthandler を有効にした状態で得たスタックトレースをつけて) コメントしてください。
