Более быстрый способ компиляции факторных программ

Question

Я действительно люблю язык Фактора. Но я нахожу, что компиляция программ, написанных на ней, невероятно медленная, и поэтому невозможно создавать реальные проекты с помощью Factor.

Например, на моем ноутбуке компиляция примера калькулятора WebApp занимает около 5 минут (процессор i3, 2 ГБ ОЗУ, Fedora 15).

Я искал вокруг, но не мог найти более быстрый способ компиляции программ Factor, чем использование интерпретатора (двоичного исполняемого файла главного фактора).

Это становится смешным, когда вы пытаетесь использовать интерпретатор только для каждого запуска, а не "развертывать" вашу программу в собственном двоичном файле (который даже не работает на многих программах). Это означает, что каждый раз, когда я хочу запустить Калькулятор, например, мне приходится ждать 5 минут холодного запуска.

Я хотел бы знать, является ли это общей проблемой, и есть ли хороший способ решить это.

Answer 1

Я признаю, что до сегодняшнего дня я никогда не слышал о факторе. Я воспользовался возможностью, чтобы поиграть с ним. Это выглядит красиво (напоминает мне о Squeak-VM и LISP одновременно). Я перережу болтун (очень каламбур) иперейду к вашему вопросу.

Анализ

Кажется, что то, как работает Factor, приводит к медленной загрузке словарей.

Я скомпилировал Фактор на моей 64-битной системе Linux Quadcore (из git revision60b1115452, Чт 6 октября). Чтобы поместить все в tmpfs, сборочный каталог занимает 641Mb, из которых 2x114Mb находится в factor.image и его резервной копии (factor.image.fresh).

когда strace- при загрузке приложения калькулятора загружается огромный список файлов факторов:

• 3175 факторных файлов затронуты.
• компиляция этого занимает около 30 секунд на моем ящике
• использование памяти максимально до500 МБ(виртуальных) и 300 МБ зарезервированного набора

Я сильно подозреваю, что в вашем ящике мало памяти, и, возможно, он становится очень быстрым
_{Это определенно объясняет сборку, занимающую 5 минут}

Можете ли вы подтвердить, так ли это (вероятно, если вы используете какой-то общий хост или устройство VPS). Если вы используете виртуальную машину, рассмотрите возможность увеличения доступной системной памяти.

---

Сохранение изображений кучи (снимки)

Я уже упоминал файл factor.image (114Mb) ранее. Он содержит "предварительно скомпилированный" (фактически загруженный)образ кучи для виртуальной машины Factor. Все операции на виртуальной машине (работа с прослушивателем пользовательского интерфейса или компиляция факторных файлов) влияют на образ кучи.

Чтобы избежать перекомпиляции ваших исходных файлов снова и снова, вы можете сохранить конечный результат в собственном образе кучи:

http://docs.factorcode.org/content/article-images.html

Изображений

Чтобы запустить Factor с пользовательским изображением, используйте ключ командной строки -i=image; см. Переключатели командной строки для виртуальной машины.

Одна из причин сохранения пользовательского изображения заключается в том, что вы загружаете одни и те же библиотеки в каждом сеансе Factor; некоторым библиотекам требуется немного времени для компиляции, поэтому сохранение изображения с загруженными библиотеками может сэкономить вам много времени.

Например, чтобы сохранить изображение с загруженным веб-фреймворком,

USE: furnace
save

Новые изображения могут быть созданы с нуля: начальная загрузка новых изображений

Развертывание приложений

Сохранение изображений кучи приводит к файлам, которые (как правило) будут больше, чем исходное изображение начальной загрузки.

Средство развертывания приложений создает урезанные изображения, содержащие достаточно кода для запуска одного приложения.

Автономный инструмент развертывания приложений, реализованный в словаре tools.deploy, компилирует словарь в собственный исполняемый файл, который запускает словарь MAIN: hook. Развернутые исполняемые файлы не зависят от устанавливаемого Factor и не предоставляют никакого исходного кода, и, следовательно, подходят для доставки коммерческих приложений для конечных пользователей.

В большинстве случаев слова в словаре tools.deploy не должны использоваться напрямую; вместо этого используйте инструмент пользовательского интерфейса развертывания приложений.

Вы должны явно указать основные подсистемы, которые требуются, а также уровень необходимой поддержки отражения. Это делается путем изменения конфигурации развертывания до развертывания.

итоговый

Я ожидаю, что вы выиграете от (в порядке быстрой победы):

• увеличение доступной оперативной памяти_{^{(только быстро в виртуальных средах...)}}
• сохранение изображения кучи с

  USE: db.sqlite
  USE: furnace.alloy
  USE: namespaces
  USE: http.server
  save
  

  Этот шаг привел к компиляции в моей системес ~30sв0.835s

• Развертывание веб-приложения калькулятора на разделенное изображение кучи (советы по развертыванию см. в источнике)

Короче говоря, спасибо за то, что привлекли Фактор к моему вниманию, и я надеюсь, что мои выводы будут полезны, ура