LuaJIT書いてて楽しいなー、速度も速いなーと思って、いざめちゃくちゃヘビーな用途につっこんで見たら、死んだ。
メモリ使用率が100%頭打ちになって、速度が劇的に低下する、いわゆるGC問題的なやつ。おそらくだけど重いメモリアロケーションが毎フレームあるやつ。
正直まぁよくあることなので、メモリプロファイリングしたり、Cとの通信箇所を精査してメモリの扱いを変えたりなどすれば良いのは頭ではわかっているものの、普段OdinやRust、C++等の非GC言語に書き慣れているとどうもこのプロセスがおっくうで、しかも非GC言語の方がメモリプロファイリング機能は充実しているという逆転現象が起きがちなので、悩む。
例えばNeluaとかを使って、GCを使わずに手動管理したりアリーナアローケータを使ったりすればいいかなーと思わなくもないけれど、そうするとNimやOdinなど別の言語でよくない？とどうしても思ってしまって、だんだんとLua熱が下がってきている。
自分は好きな言語がClojureなので、いつもJavaやJavaScriptで書きたいと思いながらなぜ書かないかがここにあって、いざ手動メモリ管理したいときにできない問題がある。とはいえ、通常のLuaやLuaJITであれば、C FFIが使えるので極端な話、C FFI経由して何でもできるけれど、Love2D や LoVR だと、元ソースをいじったり調査したりしないことにはC FFI経由のオブジェクト等が直接やり取りできないので、大抵はLua GCと仲良くならねばならないことになる。
特に今回、スレッド処理でバックグラウンドで毎フレーム更新した動画フレームを取得するなどの処理だったため、Cであれば毎フレームのメモリアロケーションは避け、使いまわしてデータポインタを直接やり取りするところ。Luaにも似たAPIはなくはないけれど、わざわざLuaでやるかなと思うとやっぱりLua熱が下がる結果になっている。
スクリプト言語で好きに楽しく書ける部分は、正直他の言語でも好きに楽しく書ける部分ではあるので、こういうコアなところこそ楽しく書きたいなと思うと、悩ましい。
本心ではこの用途ではNimを書いていきたい気はするのだけれど、V言語のような良い感じのCトランスパイラになっていないため、トランスパイル後のC言語のデバッグが正直辛すぎる。ここに、C言語を一種のアセンブリとしか捉えていないNimと、可読性の高いC言語を出力するV言語のスタンスの違いが出てしまっている。
どうしたもんかな。Odinに戻るか、Neluaとかを掘るか、あるいはLuaJIT関係のAPIを深堀りして入念に調査したり最適化するか、もしくはLove2D / LoVRのC++と直接やり取りできるAPI（Godotでいうところのgdextension）を調べるか・・・。
