8

我真的很喜欢Factor语言。但是我发现编译用它编写的程序非常慢，因此用 Factor 创建真正的项目是不可行的。

例如，在我的笔记本电脑（i3 处理器，2GB RAM，运行 Fedora 15）上编译示例Calculator WebApp大约需要 5 分钟。

我四处搜索，但找不到比使用解释器（主要因素二进制可执行文件）更快的编译因子程序的方法。

当您尝试仅在每次运行时使用解释器而不是将程序“部署”到本机二进制文件（甚至在许多程序上都不起作用）时，这变得很荒谬。这意味着每次我想运行计算器，例如，我必须等待 5 分钟的冷启动持续时间。

我想知道这是否是一个常见问题，以及是否有解决它的好方法。

4

1 回答 1

13

我承认，在今天之前，我从未听说过Factor。我借此机会和它一起玩。它看起来不错（同时让我想起了 squeak-vm 和 lisp）。我会切断smalltalk（双关语非常有意）并跳到你的问题。

分析

看来 Factor 的工作方式导致加载词汇表很慢。

我在我的 64 位四核 linux 系统上编译了 Factor（来自 git revision 60b1115452，Thu Oct 6）。将所有内容放在tmpfs上，构建目录需要 641Mb，其中 2x114Mb 位于 factor.image 及其备份 (factor.image.fresh) 中。

加载计算器应用程序时strace，会加载大量因子文件：

  • 3175个因子文件被触动。
  • 在我的盒子上编译这些大约需要30 秒
  • 内存使用量在500Mb（虚拟）和 300Mb 保留集下达到最大值

我强烈怀疑您的机器内存不足，并且可能变得非常易交换
这肯定会解释编译需要 5 分钟

您能否确认是否是这种情况（如果您正在运行某种共享主机或 VPS 设备）。如果您运行虚拟机，请考虑增加可用系统内存。

保存堆图像（快照）

我之前已经提到过 factor.image 文件（114Mb）。它包含 Factor VM 的“预编译”（实际上是引导）堆映像。VM 中的所有操作（处理 UI 侦听器或编译因子文件）都会影响堆映像。

为了避免一次又一次地重新编译源文件，您可以将最终结果保存到自定义堆映像中：

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

图片

要使用自定义图像启动 Factor，请使用 -i=image 命令行开关；请参阅VM 的命令行开关。

保存自定义图像的一个原因是，如果您发现自己在每个 Factor 会话中加载相同的库；一些库需要一些时间来编译，因此在加载这些库的情况下保存图像可以为您节省大量时间。

例如，要保存加载了 Web 框架的图像，

USE: furnace
save

可以从头开始创建新图像：引导新图像

部署应用程序

保存堆映像会导致文件（通常）比原始引导映像大。

应用程序部署工具创建精简的图像，其中包含足够的代码来运行单个应用程序

在tools.deploy词汇表中实现的独立应用程序部署工具将词汇表编译为运行词汇表的MAIN:挂钩的本机可执行文件。部署的可执行文件不依赖于安装的 Factor，并且不公开任何源代码，因此适用于交付商业最终用户应用程序。

大多数时候，tools.deploy词汇表中的单词不应该直接使用；而是使用应用程序部署 UI 工具。

您必须明确指定所需的主要子系统以及所需的反射支持级别。这是通过在部署之前修改部署配置来完成的。

结束语

我希望您会受益于（按最快获胜顺序）：

  • 增加可用内存（仅在虚拟环境中快速...）
  • 保存堆图像
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`**
  • 将计算器 webapp 部署到剥离的堆映像（请参阅源代码以获取部署提示）

简而言之，感谢您引起我的注意，我希望我的发现能有所帮助，干杯

于 2011-10-07T00:22:52.590 回答