Ответ 1
Короткий ответ
Используйте NodeJS в качестве интерпретатора JavaScript для предварительной компиляции (или другого интерпретатора JavaScript, характеризующегося низким потреблением памяти).
Более длинный ответ
В контексте я использую NodeJS 4.5.0 по сравнению с therubyracer v0.12.2 и therubyrhino v2.0.4
Можете ли вы увеличить объем оперативной памяти?
Звучит глупо, но до усложнения процесса сборки может иметь смысл увидеть, доступны ли более доступные машины сборки или доступно пространство подкачки (хотя это, вероятно, увеличит время сборки).
Можете ли вы переключить интерпретаторы JavaScript?
Использование высокопроизводительного ОЗУ, как представляется, является фундаментальной характеристикой как therubyrhino (интерпретатор Mozilla Rhino JavaScript) и therubyracer (интерпретатор JavaScript V8). Как представляется, не существует эффективного способа значительно сократить объем оперативной памяти, потребляемой на этапе предварительной компиляции активов. Наиболее жизнеспособные пути, по-видимому, предкомпилируют активы за пределами жизненного цикла сборки и кэшируют их где-то, чтобы их можно было извлечь, а не прекомпилировать, как было предложено @user4776684. Как следует из комментариев по этому вопросу, обе версии Rails и Ruby имеют влияние, но не так сильно, как интерпретатор JavaScript.
Если все остальное не выполнено
Как @slowjack2k, упомянутый выше, при использовании Bundler, параллельная конфигурация может быть использована для вызова NodeJS только для задачи прекомпиляции и сохранения исходной сборки относительно нетронутой. Я не смотрел на это, так как было проще переключать интерпретаторы, но пока я мог прекомпилировать активы с помощью рейка и NodeJS, они, похоже, не считались предварительно скомбинированными, когда речь шла о вызове rake + therubyrhino, поэтому они были повторно прекомпилирована. Я выполнил это с помощью программно заданной переменной среды BUNDLE_GEMFILE, которая указала на полностью отдельный gemfile, который использовал MRI Ruby и NodeJS вместо JRuby и therubyrhino.