Bug-org 1497746 Reduce footprint of TextEditor
初回投稿日時: 2018年12月07日00時33分38秒
最終更新日時: 2018年12月12日00時03分38秒
カテゴリ: Editor Mozilla Core Mozilla65 バグ修正
SNS:
Tweet (list)
他のバグの修正中に気付いたのですが、<input>
要素や<textarea>
要素の数だけインスタンス化されるTextEditor
クラスが64bit版では544バイトも使っていました。さらに悪いことに、Geckoで採用しているjemallocは、メモリのフラグメンテーションを抑制するために、特定のサイズ内のメモリ確保時には、それが収まる容量用に確保されたエリアに確保されます。このボーダーラインが512バイトということもあり、今まではTextEditor
クラスのインスタンスはひとつあたり1024バイトも使うということになってしまっていました。
TextEditor
やその基底クラスであるEditorBase
のメンバを確認してみると、そのうちの多くが実際にユーザのアクションに反応して、もしくは、Webアプリからの指示で編集中にのみ必要なものが非常に多いことが分かりました。
ここで、Bug-org 1465702の修正が思わぬ形で使えることが分かりました。このバグの修正により、エディタは編集中にのみ、一時的にスタック上にクラスをインスタンス化し、それを簡単に参照できるようにしています。そのため、上述のメンバは全てこの中に移動できるのです。
さらに、メモリフラグメンテーションの抑制と、メモリ確保時のオーバーヘッド削減のために、確実に登録されていたエディタの様々なリスナを登録するための配列に確保していた容量も、Quantum Flowプロジェクトでそのリスナが減った結果、予約しなくてよくなっていることも発見しました。
これらを削減することにより、バグの登録時には512バイトのラインを少し割れば良いかなと思っていたものが、なんと、400バイトにまで削減することに成功しました。つまり、<input>
要素や<textarea>
要素ひとつひとつで消費されるメモリ量がエディタ部分に関しては半減します。スタック内に一時的に確保すれば十分なものをヒープに確保してはいけませんね、というのを実感したバグでした。
ちなみに、macOSネイティブアプリのアロケータもjemallocらしいので、macOSを使っていると、この辺に明るくないアプリ開発者が作ったアプリに無駄にメモリを使われてる事が多いんではないかなという気はします。