自作モジュールは必要なのか

処理時間を計測する

-m cProfile -s cumtime を追加するだけ

python3 -m cProfile -s cumtime myprog.py

.py

for p in glob.glob("**/*.jpg"):
    print(p)

ならば、jpgファイルを全数探し終わってなくても、表示を開始する。

.py

for p in sorted(glob.glob("**/*.jpg")):
    print(p)

とすると、全数探して、並び替えを完了してからでないと表示が始まらない。

.py

a = [1, 2, 3]
a = a + [4, 5, 6]

良い例

.py

a = [1, 2, 3]
a.extend([4, 5, 6])

さらには、配列の大きさが予めわかっている場合には、最初にnp.zeros(shape, dtype=np.float) などとして領域を確保してから、
該当の行を代入していくということで、領域の確保に関する処理時間を減らせることがあります。

#pragma omp parallel

をキーワードに検索してみてください。

numpyでの実装をpytorchでの実装に書き換えて、GPUを使っての動作を高速化させる。
ChatGPTでも次の質問に答えて例を書いてくれます。
「numpy をpytorchに書き換える例を示してください。」
CPU-GPU 間のメモリ転送を減らす。
deploy 環境に合わせたモデルに変換する。
例: pytorch -> TensorRT
例： pyTorch -> onnx

数値データをasciiデータファイルで保存し、
asciiデータファイルを数値データとして読み込むのは
処理が重くなります。

対象のデータファイルにバイナリモードがあれば、
バイナリデータでデータを保存し、それを読み込むようにします。

例：点群データのply ファイルにもASCIIとバイナリの2つのバージョンが存在します。
利用するツールやライブラリがバイナリモードがあれば、
その分、処理が速くなります。

OpenCVのモジュールは、build 条件によって性能が著しく変化します。
CPUの種類に応じた最適化が入っているか
Video I/O: はどうなっているのか
などです。

GStreamer:
を使いたければ、CMakeでGStreamerを有効化する設定にして、cmake, make しなければなりません。

スクリプトの動作改善するためには、
必ず使うとは限らないライブラリのimportは後回しにするのも手だ。

Dockerfile の記述のうち、変更を生じやすいものを後ろにする。
変更を生じない部分は、前回のdocker build の結果が利用されるので、変更部分以降しか処理されない。