-hや--helpでのヘルプメッセージの表示は一瞬で終わってほしいと言う話

python egoist

egoistを作っていて、けっこう気にしているポイントなども記事にしてみることにする。個人的には-hや--helpに時間が掛かるCLIはあまり好きではない。 具体的には0.5sくらいでちょっとストレスを感じ、1.0sを越えると、使うたびに感じるストレスがそのツールの使用を遠ざけようとする程度には苦手1。

pythonで気にしたいモジュールたち

方針としては、ヘルプメッセージが出るまでに行われるimportをへらすこと。

例えば、pandasは完全に避けたい(2)。キャッシュや諸々が効かない初回は遅い3。

$ time python -c 'import pandas'

real    0m1.087s
user    0m0.693s
sys 0m0.287s

$ time python -c 'import pandas'

real    0m0.651s
user    0m0.663s
sys 0m0.123s

jinja2も、以前に比べれば早くなったとはいえ避けたい。これ一つ程度ならまだ大丈夫ではあるけれど。似たような規模のモジュールが増えてくると厳しくなってくる。

$ time python -c 'import jinja2.environment'

real    0m0.233s
user    0m0.096s
sys 0m0.024s

$ time python -c 'import jinja2'

real    0m0.123s
user    0m0.096s
sys 0m0.022s

標準ライブラリでは、asyncioもけっこう遅めのライブラリ。

$ time python -c 'import asyncio'

real    0m0.263s
user    0m0.099s
sys 0m0.033s

$ time python -c 'import asyncio'

real    0m0.129s
user    0m0.103s
sys 0m0.022s

この辺の読み込みが遅延されていると嬉しい。

ヘルプメッセージにかかるまでの時間

ヘルプメッセージの表示までに行われるインポートの内容を知りたい場合には、python -X importtimeのような形で実行してみれば良い。importtimeが3.7で追加されてから便利になった。その他それぞれのお好きな方法で。

egoistでの利用

どのようなことを気にしているかということを実際のコードを例に説明してみる。例えば、以下はjinja2を利用したegoistのコード例。はやい。

$ time python definitions.py -h
usage: definitions.py [-h] [--logging {CRITICAL,FATAL,ERROR,WARN,WARNING,INFO,DEBUG,NOTSET}]
                      {describe,generate,scan} ...

optional arguments:
  -h, --help            show this help message and exit
  --logging {CRITICAL,FATAL,ERROR,WARN,WARNING,INFO,DEBUG,NOTSET}

subcommands:
  {describe,generate,scan}
    describe
    generate
    scan

real    0m0.145s
user    0m0.100s
sys 0m0.025s

deps0

このときにimportされたモジュールは以下の様な感じ。jinja2などがimportされていないのはこのコードの書き手が気にするべき事になっている。

ちなみに型チェックを有効にするためのimportはtyping.TYPE_CHECKINGで囲む必要が出てくる。最も、現状のegoistでは、appのdirective(app.sharedやapp.define_dirなどのデコレーターの部分)がuntypedなので上手くいかない状態ではあるけれど。

definitions.py

from __future__ import annotations
import typing as t
from egoist.app import App, SettingsDict, parse_args

if t.TYPE_CHECKING:
    from jinja2.environment import Environment as Jinja2Environment

settings: SettingsDict = {"rootdir": "", "here": __file__}
app = App(settings)

app.include("egoist.directives.define_dir")
app.include("egoist.directives.shared")


@app.shared
def get_jinja2_environment() -> Jinja2Environment:
    from jinja2 import Environment, FunctionLoader, StrictUndefined

    env = Environment(
        loader=FunctionLoader(lambda name: open(name).read()),
        undefined=StrictUndefined,
    )
    return env


@app.define_dir("egoist.generators.dirkit:walk")
def output(
    *, fizzbuzz_template="templates/fizzbuzz.j2", inputs_template="templates/inputs.j2",
) -> None:
    from egoist.generators.dirkit import runtime

    env = get_jinja2_environment()
    with runtime.create_file(f"fizzbuzz.txt", depends_on=[fizzbuzz_template]) as wf:
        t = env.get_template(str(fizzbuzz_template))
        print(t.render(n=30), file=wf)

    with runtime.create_file(f"inputs.html", depends_on=[inputs_template]) as wf:
        t = env.get_template(str(inputs_template))
        print(t.render(), file=wf)


if __name__ == "__main__":
    for argv in parse_args(sep="-"):
        app.run(argv)

ちなみに実際に実行してあげた場合の依存はこんな感じ。

$ time python definitions.py generate
[F] no change   ./output/fizzbuzz.txt
[F] no change   ./output/inputs.html

real    0m0.317s
user    0m0.179s
sys 0m0.030s

generate

依存が多くなる。といってもこれくらいの時間だけなら全然待てる範囲かもしれない。気になってくるのはこのようなスクリプトが数十回実行される必要が出てきたようなとき（とはいえ対応としてはbulk actionを試みる方の話であり、importの遅延の今回の話ではない。昔似たような話を書いたりはしていた https://pod.hatenablog.com/entry/2020/01/18/213043）。

egoistで気にしていること

モジュールインポートの遅延に関することで、egoistで気にしていることをメモしてみる。 (ヘルプメッセージの話から少し脱線している)

実行されないタスクのコードのimportを含めたくない

例えば他にタスクが追加されたとする。generateはタスク名を指定してそのタスクだけに限定して実行する事ができる。 python definition.py generate outputというような感じに。ここで先程のoutputタスクだけが実行された場合に、全然関係ない(clikit)関係のコードが読み込まれてほしくはない。デコレーターで読み込まれる部分も遅延させたい4。

app.include("egoist.directives.define_cli")

@app.define_cli("egoist.generators.clikit:walk")
def hello(*, name: str) -> None:
    """hello message"""
    from egoist.generators.clikit import runtime, clikit

    with runtime.generate(clikit):
        runtime.printf("hello %s\n", name)

ちなみにincludeされるだけでdefine_cliなどが使われない場合には全く読み込まれない。

app.include("egoist.directives.define_cli")

このためにけっこう egoist.generators.{clikit,structskit,dirkit,filekit}の__init__.pyの書き方は気をつけていたりする。

generateではなくscanではfakeのモジュールのimport

generateの他に依存関係を気にしたい場合にscanというコマンドが使える（generateも含めてコマンドの名前は後日変わるかもしれない）。これは内部的にはdry-run的な動作を行っている。他のgenerator(filekit,clikit,structskit)は事前に依存関係がわかるが、dirkitの場合はタスクの内部を読み込む必要が出てくる。

複数のタスクで同じ値を利用したい場合にはlru_cache(1)で済ませられずapp.sharedを使っている理由の一つ。

$ time python definitions.py scan
{'output/fizzbuzz.txt': ['templates/fizzbuzz.j2'], 'output/inputs.html': ['templates/inputs.j2']}

real    0m0.225s
user    0m0.126s
sys 0m0.047s

scan

このときjinja2を読み込むことを避けたい気持ちがあった。現状はmock的なオブジェクトを返して実行しているので危険かもしれない。

ちなみにこのscanを発展させて、依存関係をMakefileやninjaファイルのような何かに出力させることも未来の機能としては考えていたりする。このときに走るpythonプロセスの数を減らしたい（bulk actionでN+1の削減）し、go generateのようなサブプロセスの実行系のタスクは直接焼き付けたい。

ただ、これらのコマンドを利用する状況は限定的かもしれないので、コマンドの追加もincludeでできるようにしたかったりする。

まとめ

ヘルプメッセージの表示までに時間がかかるコマンドは嫌い。 無駄に余計に時間がかかるのも嫌い。

  1. これは単純にタイポが多いせいなのかもしれない。動作に正確性が欠けるというような。例えばふつうの人以上に間違う数が多いのであれば、間違いによるdelayの時間も多くなる。↩

  2. 結果が遅めなのは現在利用している環境が貧弱なせいもある(2012年のmacbook air)。↩

  3. pycacheが使えるということだけでなく、OSのページキャッシュが効きやすいみたいな話もあるかもしれない（？）。複数の実行例を載せているのは遅すぎる例をあげるというのは不本意というだけ。↩

  4. 正確に言えば、__init__.pyだけが読み込まれるがそのモジュールがimportするモジュールなどは読み込まれない。↩