I'm afraid I'm not enough of an SBCL expert to grok this unaided. Are you saying that by somehow telling SBCL it's in interpret mode, that speeds up find-system? And is this surprising? I would have guessed that parsing and possibly compiling the .asd file would take most of the time...
Is this a proposed sbcl-specific optimization ?
Sent from my iPod
On Nov 16, 2009, at 7:27, Attila Lendvai attila.lendvai@gmail.com wrote:
dear list,
find-system is so slow that i took the time to look into it. this is what i've used to test:
(sb-sprof:with-profiling () (trace sb-fasl::load-as-source) (time (labels ((recurse (system-name) (let ((system (asdf:find-system system-name nil))) (dolist (child (rest (first (asdf:component-depends-on 'asdf:compile-op system)))) (recurse (asdf:find-system child nil)))))) (recurse (asdf:find-system :hu.dwim.walker nil)))))
out of the box run:
Evaluation took: 3.233 seconds of real time 2.350000 seconds of total run time (2.120000 user, 0.230000 system) [ Run times consist of 0.410 seconds GC time, and 1.940 seconds non- GC time. ] 72.69% CPU 15,573 forms interpreted 2,688 lambdas converted 5,615,673,160 processor cycles 15 page faults 128,748,160 bytes consed
when adding the following to asdf:find-system, just around the cl:load call:
#+sbcl (sb-ext:*evaluator-mode* :interpret)
Evaluation took: 1.506 seconds of real time 0.740000 seconds of total run time (0.640000 user, 0.100000 system) [ Run times consist of 0.110 seconds GC time, and 0.630 seconds non- GC time. ] 49.14% CPU 16,582 forms interpreted 56 lambdas converted 2,764,841,332 processor cycles 2 page faults 58,959,808 bytes consed
any thoughts on this?
-- attila
asdf-devel mailing list asdf-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel