Блог

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

Например, компиляция примера веб-приложения Calculator занимает около 5 минут на моем ноутбуке (процессор i3, 2 ГБ оперативной памяти, работает Fedora 15).

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

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

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

Я признаю, что до сегодняшнего дня я никогда не слышал о Factor. Я воспользовался возможностью поиграть с этим. Это выглядит красиво (напоминает мне squeak-vm и lisp одновременно). Я сокращу разговор (каламбур очень рассчитан) и перейду к вашему вопросу.

Анализ

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

Я скомпилировал Factor на своей 64-разрядной системе quadcore Linux (из редакции git 60b1115452 , 6 октября). Помещая все в tmpfs, каталог сборки занимает 641 МБ, из которых 2×114 МБ находится в factor.image и его резервной копии (factor.image.свежий).

При strace загрузке приложения calculator загружается огромный список факторных файлов:

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

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

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

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

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

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

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

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

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