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?
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
On Mon, Nov 16, 2009 at 16:02, Robert P. Goldman rpgoldman@sift.info wrote:
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...
well, the process is surprisingly slow compared to what's really happening. it's not an asdf issue, but sbcl's slow load-file. turning on the interpreted eval mode speeds it up considerably, because sbcl's compiler is focusing on code quality instead of compilation speed.
it shouldn't be a problem as the result of the compilation is thrown away anyway after a single evaluation (except maybe closures that end up being permanently stored somewhere as the sideffect of loading the .asd file)
Is this a proposed sbcl-specific optimization ?
i'm not sure that i'm aware of all the possible consequences of this (thinking of more complex .asd files defining functions, etc), but adding this to asdf visually speeds up the slow .asd parsing phase for me i see here and there. (our end projects have around 90 dependencies, some of them with multiple .asd files).
-
Attila Lendvai -
Robert P. Goldman