Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>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 <em>smalltalk</em> (pun very much intended) and jump to your question.</p> <h3>Analysis</h3> <p>It appears that the way Factor works, results in loading vocabularies being slow. </p> <p>I compiled Factor on my 64 bit quadcore linux system (from git revision <a href="http://gitweb.factorcode.org/gitweb.cgi?p=factor;a=shortlog;h=60b11154526aa9bd2896808f2e19e30b50e44bb5" rel="noreferrer"><code>60b1115452</code></a>, Thu Oct 6). Putting everything on <a href="http://en.wikipedia.org/wiki/Tmpfs" rel="noreferrer">tmpfs</a> the build dir takes 641Mb, of which 2x114Mb is in the factor.image and it's backup (factor.image.fresh).</p> <p>When <a href="http://linux.die.net/man/1/strace" rel="noreferrer"><code>strace</code></a>-ing the calculator app loading, there is a huge list of factor files being loaded: </p> <ul> <li><strong>3175</strong> factor files are touched. </li> <li>compilation of these takes roughly <strong>30 seconds</strong> on my box</li> <li>the memory usage maxes out on just under <strong>500Mb</strong> (virtual) and 300Mb reserved set</li> </ul> <blockquote> <p><em>I'm strongly suspecting your box is low on memory, and might be getting very swappy</em> <br/><sub>This would definitely explain compilation taking 5 minutes</sub></p> </blockquote> <p>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.</p> <hr> <h2>Saving Heap Images (snapshots)</h2> <p>I already mentioned the factor.image file (114Mb) before. It contains a 'precompiled' (bootstrapped, actually) <em>heap image</em> for the Factor VM. All operations in the VM (working on the UI listener or compiling <em>factor</em> files) affects the heap image.</p> <p>To avoid having to recompile your source files time and time again, you can save the end-result into a custom heap image:</p> <p><a href="http://docs.factorcode.org/content/article-images.html" rel="noreferrer">http://docs.factorcode.org/content/article-images.html</a></p> <blockquote> <h3>Images</h3> <p>To start Factor with a custom image, use the -i=image command line switch; see <a href="http://docs.factorcode.org/content/article-runtime-cli-args.html" rel="noreferrer">Command line switches for the VM</a>.</p> <p>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.</p> <p>For example, to save an image with the web framework loaded,</p> <pre><code>USE: furnace save </code></pre> </blockquote> <p>New images can be created from scratch: <a href="http://docs.factorcode.org/content/article-bootstrap.image.html" rel="noreferrer">Bootstrapping new images</a></p> <h2>Deploying applications</h2> <p>Saving heap images results in files that will (typically) be bigger than the original bootstrap image. </p> <p>The <a href="http://docs.factorcode.org/content/article-tools.deploy.html" rel="noreferrer">Application deployment tool</a> creates stripped-down images containing just enough code to run a single application</p> <blockquote> <p>The stand-alone application deployment tool, implemented in the <a href="http://docs.factorcode.org/content/vocab-tools.deploy.html" rel="noreferrer">tools.deploy</a> vocabulary, compiles a vocabulary down to a native executable which runs the vocabulary's <a href="http://docs.factorcode.org/content/word-MAIN__colon__,syntax.html" rel="noreferrer">MAIN:</a> 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.</p> <p>Most of the time, the words in the <a href="http://docs.factorcode.org/content/vocab-tools.deploy.html" rel="noreferrer">tools.deploy</a> vocabulary should not be used directly; instead, use <a href="http://docs.factorcode.org/content/article-ui.tools.deploy.html" rel="noreferrer">Application deployment UI tool</a>.</p> <p>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.</p> </blockquote> <h2>Concluding</h2> <p>I expect you'll benefit from (in order of quickest win):</p> <ul> <li>increasing available RAM <sub><sup>(only quick in virtual environments...)</sup></sub></li> <li>saving a heap image with <blockquote> <pre><code>USE: db.sqlite USE: furnace.alloy USE: namespaces USE: http.server save </code></pre> <p>This step brought the compilation on my system <strong>down from ~<code>30s</code> to <code>0.835s</code></strong></p> </blockquote></li> <li>deploying the calculator webapp to a stripped heap image (refer to the <a href="http://gitweb.factorcode.org/gitweb.cgi?p=factor;a=blob_plain;f=extra/webapps/calculator/calculator.factor;hb=HEAD" rel="noreferrer">source</a> for deployment hints)</li> </ul> <p>In short, thanks for bringing Factor to my attention, and I hope my findings will be of any help, Cheers</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload