Nukeのディスクキャッシュ

Nukeでは8bitや16bitのファイルを読み込んでも内部では32bit floatとして計算されるので、ディスクキャッシュ自体も32bit floatとなります。ディスクキャッシュはファイル形式のデコードに左右されず、ホストアプリケーション(この場合Nuke)がもっとも高速に処理できるnkcという形式のファイルが使用されます。

保存先はNukeのPreferenceで設定したフォルダになります。


ここに「00」〜「ff」までの16進数表記のフォルダが作成されNukeは必要に応じてここに分割されたキャッシュファイルを作成します。キャッシュは上記のPreferenceで設定された容量に達すると自動で削除されます(ユーザーがクリアすることも可能ですが)。自動でも行われているのであまり意識していない人もいるのではないかと思いますが。


特にDiskcacheノードやノードのcacheオプションを有効にしなくても、プレビューすると結果が自動的にここにキャッシュされます。もちろん途中でユーザーが任意にキャッシュする場合もあるわけですが、今回は一番よく使われるこのプレビューキャッシュのみで検証しています。

ディスクキャッシュはユーザーがなにか作業してプレビューするたび(正確にはビューペインが更新されるたび)に読み書きが行われます。つまりすごく頻繁に使用しているということです。ただし表示されている解像度と表示領域で最適化されるので、必ずしも完全な画像がまるごとキャッシュされているわけではありません。

今回は1280x720を等倍で全体が表示できる状態(つまり等倍でまるごとキャッシュする状態)にしてプレビューしてみます。

まずディスクキャッシュをクリアして空にします。その状態でNukeのディスクキャッシュフォルダのサイズが「21,520バイト」。ほぼゼロなのですが、フォルダが予め作成されているのでその分のデータサイズになっています。

先ほどのフッテージを読みこんで2790フレームすべてを一度プレビューするとキャッシュフォルダのサイズ合計が正確には20,586,382,480バイト。ギガバイトに直すとMacでは「25.09GB」になります。１フレームあたり計算してみると7,378,624バイト(Macでは7.4MB)です。先ほどのNukeのキャッシュフォルダの中には、まさにこのサイズのキャッシュファイル(nkcファイル)が作成されています。

1フレームあたり7.4MBということは30fpsをリアルタイムに記録または再生するなら222MB/sが必要です。実際にはNukeの処理時間もあるのでディスクの性能だけではないのですが、この転送レートを下回った場合にはハードディスクがボトルネックになっていると考えてもいいかと思います(書き込みに関しては実再生時間より短い時間でレンダリングしちゃってもいいわけですが)。222MB/sというのは、普通の(まったく断片化しない状態でも)HDD単体ではまず無理だと思います。

Nukeが重いと言われる理由はこの巨大なディスクキャッシュによるところも大きいのでは？実際に720pのQuickTIme、298.1MBを読み込んで一度プレビューするだけで、実はHDD上で25GB以上のデータが転送されているというのは予想しにくいです。

もちろんNuke内部のデータ処理はすべて32bit floatなので、HDDだけの問題ではなくCPUやメモリ(GPGPU使っているならGPU)とか全部ひっくるめてのパフォーマンスとなるわけですが、見落とされがちなキャッシュ用のストレージも見直してみるといいかもしれません。

After EffectsもCS6でキャッシュが大幅に強化されたので似たような問題が生じる可能性があります(手元にAE CS6インストールしたマシンがないので試してません)。ただディスクキャッシュが必須ではなくディスクキャッシュ自体を無効にしてしまうことも可能だし、8bitや16bitなどのモードもあるのでNukeほど顕著ではないかもしれません。


[関連記事]
Apricorn PCIe Drive Array
MacProのSSD交換
DPX 10bitは重いのか?
After Effects CS6のキャッシュがすごい