長年MacでEmacsを使って使っていたユーザーを悩ませてきた「jank(操作時の重さ)」問題。LinuxやWindowsでは快適に動作するのに、macOS上では時間の経過と共にEmacsのRAM使用量が増え、操作が重くなり、最終的にはフリーズすることもあるという現象です。開発者Przemysław Alexander Kamiński氏は、この問題の根本原因を調査したブログ記事「Emacs: The MacOS Bug」を公開し、Emacsユーザーの注目を集めています。原因は「NSApp run」の副作用筆者はmacOS向けのEmacsコード(主にnsterm.m)を調べ、問題の根源がNSApp runの呼び出しにあることを突き止めます。この処理はmacOSのイベントを処理するランループを起動しますが、ウィンドウやグラフィックコンテキストの初期化を毎回行い、特に、HiDPIディスプレイや高性能Macではとくに大量のメモリを消費しまうことになるのです。ここでは以下のような現象が発生しています。ウィンドウサイズ変更やイベント処理のたびに大量のメモリが確保・解放されるEmacs側では一部のリソース（フォントグリフやメニュー文字列など）を正しく解放できず残留macOSはこれらの残留リソースを「重要」と誤認し、キャッシュしてしまう結果として、「速いMacほどEmacsが遅くなる」という逆転現象が起こります。この現象は以下のコードで簡単に確認することができます。(dotimes (x 1000) (let ((frame (make-frame-command))) (sleep-for 0.01) (delete-frame frame)))今後の改善策残念ながら、この問題の根本解決は容易ではありません。macOS固有のコードは複雑で、変更には大きな労力を伴うからです。しかし筆者は、SwiftによるmacOS GUI部分のリファクタリングや、スレッドセーフ、非同期処理、効率的なメモリ管理による改善に期待を示しています。Hacker Newsでは、この記事に関する議論が行われていて、多くのユーザーがmacOS上のEmacsのjank問題に共感を示しています。また筆者の分析に対しても「ここまで掘り下げたのはすごい」といった技術的な称賛が寄せられています。Emacsの代替として NeovimやVS Codeを使用する、「Emacsをターミナルで使えばGUIの問題は回避できる」といった 実用的な回避策も共有されています。個人的には、これまでEmacsをターミナルでしか使っておらず、macOS特有の「jank」問題には気がついていませんでしたが、記事のおかげで、このような問題が存在したことを初めて知ることができました。