GDAL_CACHEMAX で驚きの実行速度に! しかし遅かったorz

遅いのは仕方ないと思ってた

GDALの各種ツールは便利なんだけど、正直言って遅いよな、と思ってました。
一連のゴニョゴニョが複数走っている際は、どこかで何かが終わるので、あんまり気になりませんでした。
しかし、一連のゴニョゴニョが終わりに近づいて、ジョブが1本だけになった際、とうとう処理の遅さを感じてきました。
ちゃんと動かしてるんだろうなおい、と思って top で見てみると、ちゃんとトップに来てて、しっかり動いてました。
…いや、これおかしいやん。
使用メモリが極端に少ない。数GBの画像ファイル扱ってるくせして50MBぐらいしかメモリを占有してない。

ファイルアクセスは遅い

処理をしているうちに、どこかは知りませんが、中途のデータはファイルシステムに吐き出しているはず。ファイルへのアクセスの速度は、メモリへのアクセスと比べると全く比べものにならない。このメモリの少なさが実行速度低下の理由であろう、と。
で、まず思ったのが、さすがのGDALもメモリについてはあんまり考えてないのか、ダメだな、と (このときはね)。
でもまあとりあえず調べてみる。

ジェネラルなコマンドラインのスイッチと環境変数

たどりついたのが http://www.gdal.org/gdal_utilities.html
ここはいつも見てますがな。しかし、そページの下の方の "General Command Line Switches" は見てなかった。
そこでは --config というのがあって、たとえば GDAL_CACHEMAX というのを設定できるよ、という説明。
で、そこから http://trac.osgeo.org/gdal/wiki/ConfigOptions に誘導される。
とりえあず、GDAL_CACHEMAX が関係あるなーと。
あと、環境変数でも設定できるということで、とりあえず

  setenv GDAL_CACHEMAX 4096

とかしてみる (csh系)。これで 4096MB のメモリを「キャッシュ」のために確保する、はず。

はやっ!

実行すると、はじめは4GBまで占有してなくて、あれっと思ったけれども、ほどなく4GBを超えるメモリ占有。
そして、デフォルトでは見積もり20時間の作業が30分程度で終了。
はやっ、まじではやい。

これはこれでつらい

しかし、これ今まで何で気づかんかったんだろうか…。たぶん相当な時間がセーブできたはず、しかし時間は取り戻せない、泣くしかない。
そして「GDALダメだな」と思っていたことにごめんなさいしないといけないと思った。