As the result of an attempt to reduce our startup time, I implemented binary FASL support: a compiled lisp function (= Java class) which gets executed instead of the interpreted forms which used to constitute the texty fasl format. The texty format is still there, but in case of a binary fasl only contains 2 forms to be evaluated, the rest will be in the compiled function.
I don't feel like we achieved much: my startup times used to be 0.4 s and 1.6 s and that doesn't seem to have changed. Bummer. However, that's probably to be expected, because I was just guessing where our performance issue would be: I want to know how much of the 0.4 and 1.6 seconds are actually spent waiting on I/O happening. In case we're waiting big time on the data coming from the JAR, maybe there's an optimization possible to the way we create/read the JAR file.
Any help on the subject of reducing our startup time would be most welcome!
Bye,
Erik.
On 10/25/09 11:22 PM, Erik Huelsmann wrote:
As the result of an attempt to reduce our startup time, I implemented binary FASL support: a compiled lisp function (= Java class) which gets executed instead of the interpreted forms which used to constitute the texty fasl format.
[…]
Unfortunately, [this change][1] makes the ABCL trunk compilation under both OS X (x64-darwin-10.0.0/apple-jdk-1.6.0_15) and Windows (x86-winxp-5.1_sp3/sun-jdk-1.5.0_16) fail with:
[java] ; Compiling /Users/evenson/work/abcl/build/classes/org/armedbear/lisp/compiler-types.lisp ... [java] ; (IN-PACKAGE #:SYSTEM) [java] ; (DEFSTRUCT CONSTANT-TYPE ...) [java] 2.273 seconds real time [java] 1133901 cons cells [java] [java] Caught PROGRAM-ERROR while processing --eval option "(compile-system :zip nil :quit t)": [java] Wrong number of arguments for CONVERT-TOPLEVEL-FORM.
BUILD FAILED /Users/evenson/work/abcl/build.xml:211: Java returned: 2
[1]: http://trac.common-lisp.net/armedbear/changeset/12226
armedbear-devel@common-lisp.net
-
Erik Huelsmann -
Mark Evenson