この日記はMozillaのプロダクトへの貢献者としての私の成果を中心に、気になったバグやWeb界隈の話題について書いていますが、 断り書きがある場合を除き、いかなる団体のオフィシャルな見解ではありません。あくまでも個人的なものです。 Mozilla Foundation、Mozilla Corporation、及び関連企業の公式情報ではないことに注意してください。

現在、XHTML 1.0 (もどき)から、HTML5なコンテンツに修正中です。古い日記は修正が完了していませんので表示が崩れます。 順次、修正していく予定ですのでしばらくお待ちください。

もずはっく日記(2018年12月)

2018年12月7日

Bug-org 1497746 Reduce footprint of TextEditor
初回投稿日時: 2018年12月07日00時33分38秒
最終更新日時: 2018年12月12日00時03分38秒
カテゴリ: Editor Mozilla Core Mozilla65 バグ修正
SNS: (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を使っていると、この辺に明るくないアプリ開発者が作ったアプリに無駄にメモリを使われてる事が多いんではないかなという気はします。

関連するかもしれないエントリ

bug-org 1497746を含むエントリ