LuneScript のトランスコンパイル時間を 1157 パーセント改善した件

2021-05-25

Page content

前回から引き続き LuneScript のトランスコンパイル時間短縮を行なっています。

今回の時間短縮は以下の通りです。

この表は、セルフホスティングしているソースのトランスコンパイル時間の計測結果を示しています。 lua VM で動作させた lnsc と、go でビルドした lnsc で計測しています。

改善前の 6e5661a9 は、5/6 のバージョンです。改善後の 364095ef は、5/25 のバージョンです。

この表の通り、改善前の Lua と、改善後 go のトランスコンパイル時間を比べると (/ 25.69 2.22 ) 11.572072072072071 ≒ 1157% 改善しています。

改善後の lua と go の比較では 785%、改善前と改善後の go の時間を比べると、 263% 改善しています。

今回は以下の高速化を行ないました。

以降では、今回の高速化方法ついて説明します。

meta 情報処理の高速化

LuneScript は、モジュールをインポートする際、そのモジュールが何のクラスや関数を公開いているか？を解析します。この「何のクラスや関数を公開しているか」の情報が meta 情報です。

この meta 情報を解析するには時間がかかるため、解析した meta 情報は .meta ファイルとして保存します。そして、 .meta ファイルがある場合は、そのファイルから meta 情報を取得します。

個々の .lns ファイルを一つずつトランスコンパイルする際は、この .meta から取得するのが高速化として重要です。

一方で、複数の .lns ファイルを一括してトランスコンパイルする際は、この方法は多くの無駄な処理が含まれます。

.meta ファイルを生成し、生成したファイルを読み込んで meta 情報を構築するには、以下の処理が必要です。

ちなみに、この .meta ファイルを読み込み meta 情報を構築する処理を、ここでは import 処理と言います。

例えば、 2 つのファイル(a.lns, b.lns: b.lns から a.lns を import している)を一括でトランスコンパイルする場合は以下になります。

ここで、「この解析途中に a.meta を読み込み、 meta_a 情報を構築する。」は無駄です。

なぜならば、「meta_a 情報」は AST_a に含まれており、 AST_a はメモリ上に残っているため、「a.meta を読み込み、 meta_a 情報を構築する」ことなく、メモリ上の AST_a から meta_a を取得できるからです。

以下のように import 処理を変更します。

a.meta を読み込み、 meta_a 情報を構築する。 処理と、 AST_a に含まれる meta_a 情報を取得する。 処理を比較すれば、圧倒的に後者の方が高速に処理できます。

やっていることは非常に単純ですが、これを実現するのは結構大変でした。。

トランスコンパイルは、以下の処理行ないます。

これを .lns ファイル分実行します。

例えば a.lns, b.lns, c.lns の 3 つのファイルがあった場合、次の通り処理します。

ここで、 「AST_a から .lua, .go を生成する」 、 「AST_b から .lua, .go を生成する」 、 「AST_c から .lua, .go を生成する」 の処理は、基本的には独立して処理できます。

つまり、これら処理は並列して実行可能です。

そこで go rutine を利用して、並列化しています。

しかし、直感的に 並列化可能 と言っても、実際に安全に並列化ができるかどうかは別の話です。

シングルスレッドでは問題にならないことも、マルチスレッドにすると問題になることが良くあります。

今回の 並列化処理 を実現するにあたり、マルチスレッド化を安全に論理的に実現する方法を、 LuneScript に追加しました。