Here’s the PR 
I know; I too have spent too much time debugging docker-sync than I care to admit. This new approach, albeit not as fast, requires zero additional effort to setup and is quite stable from my own experiences!
ついにMacにDiscourseをインストールしましたが、信じられないほど遅いです…ページごとに20秒もかかります。
そこで質問です：
- これはDockerの問題でしょうか、それともDiscourseのコードの問題でしょうか？
同じ問題に直面している方はいますか？
これは Docker for Mac の問題です。Mac 上で Discourse をネイティブにセットアップして開発を行うことで、パフォーマンスが劇的に向上します。
Discourse はそもそも Docker を使わないほうがいいかもしれませんね。メリットが見当たりません。正直、単なる余分なレイヤーで、コンテナのデバッグが苦痛になるだけです。ただの意見ですが。
Docker は、実行中のアプリケーションを取り巻く環境を標準化し、ホストからサンドボックス化します。
Docker を使わずに自己ホスト型のインストールをサポートしようとすると、Discourse チームにとっては悪夢になるでしょう。ホスト環境や設定は Discourse インスタンス間で大きく異なるためです。特に Mac と Linux の間では顕著です。
Docker は Linux 上ではわずかなパフォーマンス低下をもたらしますが（Mac ではより顕著ですが）、分散開発チームを持ち、数千もの自己ホスト型インスタンスを抱えるこの種のオープンソースプロジェクトにとっては、その利点は計り知れません。
商用規模でアプリケーションを運用したい場合（例：クラスターオーケストレーションに Kubernetes を使用するなど）、実装の詳細をオーケストレーターから抽象化するために、アプリケーションをコンテナ化する必要があります。
私は開発環境（Ubuntu 使用）で Docker を使っていません。むしろ、私のやり方の方が手間がかかるかもしれません。ゼロから再構築するのは非常に面倒だからです。
@cmoi さん、お返します。
Mac で開発用の新しいセットアップ（上記の投稿 #44 を参照）をインストールしたところ、非常に高速で、問題は一切ありませんでした。
他のご質問について
@cmoi さんが言っています……
もしかして、Discourse は Docker を使わない方が良いのかもしれませんね。利点がわかりません。正直、単なる追加のレイヤーで、コンテナのデバッグは苦痛になるでしょう。ただの意見ですが
当社は本番環境とステージング環境で Docker 上で Discourse を運用していますが、非常に快適です。その理由の一つは、Docker 上でセットアップする方が「物理サーバー（オンザメタル）」でセットアップするよりも、時間と手間が大幅に少なくて済むことです。また、サーバークラッシュが発生した場合の復元も Docker 上の方がはるかに容易です。
したがって、本番環境で Docker を使用する理由は数多くあり、疑いの余地はありません。
ただし、プラグイン開発に関しては、私はついに Docker を使わない「ベアメタル」環境に切り替えました。その結果、プラグインの読み込みや再読み込み、デバッグなど、そうした楽しい作業が、Docker 外の方が明らかに速く、より楽しくなることがすでにわかります。
