I admit that until today I have never heard of Factor. I took the opportunity to play with him. It looks beautiful (at the same time reminds me of squeak-vm and lisp). I will cut off a small trick (a pun is a lot) and jump to your question.
Analysis
It seems that the way Factor works slows down the loading of dictionaries.
I compiled Factor on my 64-bit quadcore linear system (from git revision 60b1115452 , thu October 6th). Having placed everything on tmpfs , the build file will have 641Mb, of which 2x114Mb is in the factor.image file, and the backup copy (factor.image.fresh).
When strace - when loading the calculator application there is a huge list of downloaded factor files:
- 3175 affected factor files.
- compiling them takes about 30 seconds in my box
- memory usage is maximized only with 500 MB (virtual) and a reserved set of 300 MB
I strongly suspect that your box is inactive in memory, and can be very fast.
This will certainly explain the 5 minute compilation
Can you confirm if this matters (probably if you are using some kind of shared host or VPS device). If you run a virtual machine, consider expanding the available system memory.
Saving Heap Images (Snapshots)
I already mentioned factor.image file (114Mb) before. It contains a "pre-compiled" (loaded, actually) heap image for a factor virtual machine. All operations in the virtual machine (running on the user interface or compiling factor files) affect the heap image.
In order not to recompile the source files again and again, you can save the final result in a custom heap image:
http://docs.factorcode.org/content/article-images.html
Images
To start Factor with a custom image, use the command line switch -i = image; see Command line switches for a virtual machine .
One of the reasons for saving a custom image is that you load the same libraries in every Factor session; some libraries take a little time to compile, so saving an image with loaded libraries can save you a lot of time.
For example, to save an image with a loaded web map,
USE: furnace save
New images can be created from scratch: Download source images
Application Deployment
Saving heap images results in files that (usually) will be larger than the initial boot image.
Application Deployment Tool creates truncated images containing enough code to run a single application
The stand-alone application deployment tool, implemented in the tools.deploy dictionary, compiles the dictionary into its own executable file, which launches the MAIN: hook dictionary. The deployed executable files do not depend on the installed Factor and do not reveal any source code and, therefore, are suitable for the delivery of commercial applications to the end user.
In most cases, the words in the tools.deploy dictionary should not be used directly; use the Application Deployment UI Tool instead.
It is necessary to clearly indicate the main subsystems that are required, as well as the necessary level of support for reflection. This is done by changing the deployment configuration before deployment.
Conclusion
I expect you to win (in quick win order):
- increase in available random access memory (only in virtual environments)
- saving heap with
USE: db.sqlite USE: furnace.alloy USE: namespaces USE: http.server save
This step led the compilation on my system down from ~ 30s to 0.835s
- deploying a webapp calculator with a split heap image (see source for deployment tips)
In short, thanks for bringing Factor to my attention, and I hope that my results will be useful, Cheers