Я признаю, что до сегодняшнего дня я никогда не слышал о Факторе. Я воспользовался возможностью, чтобы поиграть с ним. Это выглядит красиво (напоминает мне о Squeak-VM и LISP одновременно). Я отрежу smalltalk (очень каламбур) и перейду к вашему вопросу.
Анализ
Похоже, что способ, которым работает Factor, приводит к медленной загрузке словарей.
Я скомпилировал Factor в моей 64-битной системе Linux Quadcore (из git revision 60b1115452, четверг, 6 октября). Помещая все в tmpfs , сборочный каталог занимает 641Mb, из которых 2x114Mb находится в factor.image и его резервной копии (factor.image.fresh).
Когда strace при загрузке приложения калькулятора, загружается огромный список файлов факторов:
- 3175 файлы факторов затронуты.
- их сборка занимает примерно 30 секунд на моей коробке
- Максимальное использование памяти - 500 МБ (виртуальный) и 300 МБ зарезервированный набор
Я сильно подозреваю, что в вашем ящике недостаточно памяти, и, возможно, он очень загружается
Это определенно объясняет, что компиляция занимает 5 минут
Можете ли вы подтвердить, так ли это (вероятно, если вы используете какой-то общий хост или устройство VPS). Если вы используете виртуальную машину, рассмотрите возможность увеличения доступной системной памяти.
Сохранение изображений кучи (снимков)
Я уже упоминал файл factor.image (114Mb) ранее. Он содержит «предварительно скомпилированный» (фактически загруженный) образ кучи для виртуальной машины Factor. Все операции на виртуальной машине (работа с прослушивателем пользовательского интерфейса или компиляция файлов factor ) влияют на образ кучи.
Чтобы избежать необходимости перекомпилировать исходные файлы снова и снова, вы можете сохранить конечный результат в собственном образе кучи:
http://docs.factorcode.org/content/article-images.html
Изображения
Чтобы запустить Factor с пользовательским изображением, используйте ключ командной строки -i = image; см. Переключатели командной строки для VM .
Одной из причин сохранения пользовательского изображения является то, что вы загружаете одни и те же библиотеки в каждом сеансе Factor; некоторым библиотекам требуется некоторое время для компиляции, поэтому сохранение изображения с загруженными библиотеками может сэкономить вам много времени.
Например, чтобы сохранить изображение с загруженным веб-фреймворком,
USE: furnace
save
Новые изображения могут быть созданы с нуля: Начальная загрузка новых изображений
Развертывание приложений
Сохранение изображений кучи приводит к файлам, которые (как правило) будут больше, чем исходное изображение начальной загрузки.
Инструмент развертывания приложений создает урезанные изображения, содержащие достаточно кода для запуска одного приложения
Автономный инструмент развертывания приложений, реализованный в словаре tools.deploy , компилирует словарь в собственный исполняемый файл, который запускает хук словаря MAIN: . Развернутые исполняемые файлы не зависят от устанавливаемого Factor и не предоставляют никакого исходного кода, и поэтому подходят для доставки коммерческих приложений для конечных пользователей.
В большинстве случаев слова в словаре tools.deploy не должны использоваться напрямую; Вместо этого используйте Инструмент пользовательского интерфейса развертывания приложений .
Вы должны явно указать основные подсистемы, которые требуются, а также необходимый уровень поддержки отражения. Это делается путем изменения конфигурации развертывания перед развертыванием.
Заключительный
Я ожидаю, что вы выиграете (в порядке быстрого выигрыша):
- увеличение доступной оперативной памяти (только быстро в виртуальных средах ...)
- сохранение изображения кучи с
USE: db.sqlite
USE: furnace.alloy
USE: namespaces
USE: http.server
save
Этот шаг привел к компиляции в моей системе с ~ 30s до 0.835s
- Развертывание веб-приложения калькулятора на разделенном образе кучи (советы по развертыванию см. В источнике )
Короче, спасибо за то, что обратили внимание на Factor, и я надеюсь,мои выводы будут полезны, ура