[armedbear-devel] fast-boot-preloading branch merged to trunk
After finding on the fast-boot-preloading branch that the experiment worked out: delaying access to the reflection API in order to save performance worked! Comparing the branch performance of loading ABCL on Google App Engine to the trunk, the trunk took rougly 19 seconds to load (theoretical performance) while the branch only took 11 seconds. Seeing this benefit, I decided to merge the code back to trunk once the branch was stable enough. Today was that moment: I found the last reason the branch was failing the ANSI tests (I needed to increase the runtime stack). Given this status, the merge of the branch to the trunk just got committed. The work isn't fully done though: 1. The same approach can be implemented for macro-functions 2. Functions loaded through EVAL-WHEN during file compilation can be addressed the same way Anybody with time to help out on either is heartily invited to join the effort and see how much compile time and boot time can be saved. With kind regards, Erik.
On 12/25/09 5:35 PM, Erik Huelsmann wrote: […]
Seeing this benefit, I decided to merge the code back to trunk once the branch was stable enough. Today was that moment: I found the last reason the branch was failing the ANSI tests (I needed to increase the runtime stack). Given this status, the merge of the branch to the trunk just got committed.
SLIME breaks pretty badly post [svn r12306] leading to the following exception: ; Loading /Users/evenson/.slime/fasl/2009-12-23/armedbear-0.18.0-dev-darwin-unknown/swank-backend.abcl ... java.lang.NullPointerException at org.armedbear.lisp.Lisp.loadClassBytes(Lisp.java:1439) at org.armedbear.lisp.Lisp.loadClassBytes(Lisp.java:1433) at org.armedbear.lisp.AutoloadedFunctionProxy.loadPreloadedFunction(AutoloadedFunctionProxy.java:191) at org.armedbear.lisp.CompiledClosure$1.execute(CompiledClosure.java:224) at org.armedbear.lisp.LispThread.execute(LispThread.java:562) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:494) at org.armedbear.lisp.Lisp.eval(Lisp.java:459) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:496) The backtrace function seems pretty borked as well, in this non-SLIME test case: Armed Bear Common Lisp 0.18.0-dev Java 1.6.0_17 Apple Inc. Java HotSpot(TM) 64-Bit Server VM Low-level initialization completed in 0.428 seconds. Startup completed in 1.111 seconds. Type ":help" for a list of available commands. CL-USER(1): (defun foo () (break)) FOO CL-USER(2): (foo) Debugger invoked on condition of type SIMPLE-CONDITION: BREAK called Restarts: 0: CONTINUE Return from BREAK. 1: TOP-LEVEL Return to top level. [1] CL-USER(3): :bt 0: (SYSTEM:BACKTRACE) 1: Debugger invoked on condition of type STORAGE-CONDITION: java.lang.StackOverflowError at org.armedbear.lisp.clos_108.execute(clos.lisp:1026) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:93) at org.armedbear.lisp.StandardGenericFunction.execute(StandardGenericFunction.java:131) at org.armedbear.lisp.LispThread.execute(LispThread.java:562) at org.armedbear.lisp.clos_105.execute(clos.lisp:1003) at org.armedbear.lisp.Symbol.execute(Symbol.java:781) at org.armedbear.lisp.LispThread.execute(LispThread.java:579) at org.armedbear.lisp.clos_108.execute(clos.lisp:1026) I'm on the go for the next couple days, so I don't have a whole lot of time to help track this down, but I wanted to give Erik a head's up. Mark -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."
participants (2)
-
Erik Huelsmann -
Mark Evenson