我承认，在今天之前，我从未听说过 Factor。我借此机会和它一起玩。它看起来不错（同时让我想起了 squeak-vm 和 lisp）。我会删掉 smalltalk（非常有意的双关语）并跳到你的问题。
分析
Factor 的工作方式似乎导致加载词汇表很慢。
我在我的 64 位四核 linux 系统上编译了 Factor（来自 git 修订版60b1115452，10 月 6 日星期四）。将所有内容放在tmpfs 上，构建目录需要 641Mb，其中 2x114Mb 位于 factor.image 及其备份 (factor.image.fresh) 中。
当strace-ing 计算器应用程序加载时，正在加载大量因子文件：
-
3175 个因子文件被触摸。
- 在我的机器上编译这些大约需要 30 秒
- 内存使用量在 500Mb（虚拟）和 300Mb 保留集下达到最大值
我强烈怀疑你的机器内存不足，并且可能变得非常易交换
这肯定会解释编译需要 5 分钟
您能否确认是否是这种情况（如果您正在运行某种共享主机或 VPS 设备）。如果您运行虚拟机，请考虑增加可用系统内存。
保存堆图像（快照）
我之前已经提到过 factor.image 文件（114Mb）。它包含 Factor VM 的“预编译”（实际上是引导）堆映像。 VM 中的所有操作（处理 UI 侦听器或编译 factor 文件）都会影响堆映像。
为避免一次又一次地重新编译源文件，您可以将最终结果保存到自定义堆映像中：
http://docs.factorcode.org/content/article-images.html
图片
要使用自定义图像启动 Factor，请使用 -i=image 命令行开关；见Command line switches for the VM。
保存自定义图像的一个原因是，如果您发现自己在每个 Factor 会话中加载相同的库；一些库需要一些时间来编译，因此在加载这些库的情况下保存图像可以节省大量时间。
例如，要保存加载了 Web 框架的图像，
USE: furnace
save
可以从头开始创建新图像：Bootstrapping new images
部署应用程序
保存堆映像会导致文件（通常）大于原始引导映像。
Application deployment tool 创建精简的图像，其中包含足够的代码来运行单个应用程序
在tools.deploy 词汇表中实现的独立应用程序部署工具将词汇表编译为运行词汇表的MAIN: 挂钩的本机可执行文件。部署的可执行文件不依赖于所安装的 Factor，并且不公开任何源代码，因此适用于交付商业最终用户应用程序。
大多数时候，tools.deploy 词汇表中的单词不应该直接使用；请改用Application deployment UI tool。
您必须明确指定所需的主要子系统，以及所需的反射支持级别。这是通过在部署之前修改部署配置来完成的。
结束
我希望您会从中受益（按最快获胜顺序）：
- 增加可用 RAM （仅在虚拟环境中快速...）
- 保存堆图像
USE: db.sqlite
USE: furnace.alloy
USE: namespaces
USE: http.server
save
This step brought the compilation on my system **down from ~`30s` to `0.835s`**
- 将计算器 Web 应用部署到剥离的堆映像（有关部署提示，请参阅 source）
简而言之，感谢您让我注意到 Factor，我希望我的发现对您有所帮助，干杯