私はFactor言語が大好きです。しかし、Factor で書かれたプログラムのコンパイルは非常に遅く、Factor で実際のプロジェクトを作成することは現実的ではありません。
たとえば、サンプルのCalculator WebAppをコンパイルするには、私のラップトップ (i3 プロセッサ、2GB RAM、Fedora 15 を実行) で約 5 分かかります。
あちこち検索しましたが、インタプリタ (メインの factor バイナリ実行可能ファイル) を使用するよりも速く Factor プログラムをコンパイルする方法を見つけることができませんでした。
実行ごとにインタープリターのみを使用し、プログラムをネイティブバイナリファイルに「展開」しないと、ばかげたことになります(多くのプログラムでは機能しません)。これは、たとえば、Calculator を実行するたびに、5 分間のコールド スタート期間を待たなければならないことを意味します。
これが一般的な問題であるかどうか、およびそれに取り組む良い方法があるかどうかを知りたいです。
I admit that before today, I had never heard of Factor. I took the opportunity to play with it. It is looking nice (reminds me of squeak-vm and lisp at the same time). I'll cut the smalltalk (pun very much intended) and jump to your question.
It appears that the way Factor works, results in loading vocabularies being slow.
I compiled Factor on my 64 bit quadcore linux system (from git revision 60b1115452, Thu Oct 6). Putting everything on tmpfs the build dir takes 641Mb, of which 2x114Mb is in the factor.image and its backup (factor.image.fresh).
When strace-ing the calculator app loading, there is a huge list of factor files being loaded:
I'm strongly suspecting your box is low on memory, and might be getting very swappy
This would definitely explain compilation taking 5 minutes
Can you confirm whether this is the case (likely if you are running some kind of shared host or VPS appliance). If you run a virtual machine, consider increasing the available system memory.
I already mentioned the factor.image file (114Mb) before. It contains a 'precompiled' (bootstrapped, actually) heap image for the Factor VM. All operations in the VM (working on the UI listener or compiling factor files) affects the heap image.
To avoid having to recompile your source files time and time again, you can save the end-result into a custom heap image:
http://docs.factorcode.org/content/article-images.html
Images
To start Factor with a custom image, use the -i=image command line switch; see Command line switches for the VM.
One reason to save a custom image is if you find yourself loading the same libraries in every Factor session; some libraries take a little while to compile, so saving an image with those libraries loaded can save you a lot of time.
For example, to save an image with the web framework loaded,
USE: furnace save
New images can be created from scratch: Bootstrapping new images
Saving heap images results in files that will (typically) be bigger than the original bootstrap image.
The Application deployment tool creates stripped-down images containing just enough code to run a single application
The stand-alone application deployment tool, implemented in the tools.deploy vocabulary, compiles a vocabulary down to a native executable which runs the vocabulary's MAIN: hook. Deployed executables do not depend on Factor being installed, and do not expose any source code, and thus are suitable for delivering commercial end-user applications.
Most of the time, the words in the tools.deploy vocabulary should not be used directly; instead, use Application deployment UI tool.
You must explicitly specify major subsystems which are required, as well as the level of reflection support needed. This is done by modifying the deployment configuration prior to deployment.
I expect you'll benefit from (in order of quickest win):
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`**
In short, thanks for bringing Factor to my attention, and I hope my findings will be of any help, Cheers