Сокращение потребления памяти в рейк-активах: прекомпиляция

Проблема:
У меня заканчивается оперативная память при выполнении задачи rake assets:precompile в автоматическом сборке. Существуют ли какие-либо стратегии для инкрементного прекомпиляции или каким-либо другим способом выполнить этап прекомпиляции без использования как можно большего количества ОЗУ? Похоже, что эта задача занимает около 850 МБ больше, чем базовая линия для сборки.

Контекст:
Я пытаюсь получить одну версию Docker контейнера Bitbucket Pipelines для нашей автоматической сборки. В стек приложений входят Rails 4.2.7, PostgreSQL 9.3, Java 8, Maven 3.3.9 и JRuby 9.1.2.0. Я попытался создать образ, основанный на Debian Jessie, а также на Alpine Linux, но он не имеет большого значения в базовой памяти.

Короткий ответ

Используйте 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.