ABCL vs SBCL quicklisp load time in .rc files

220 views
Skip to first unread message

Dave Tenny

unread,
Nov 5, 2013, 6:36:51 AM11/5/13
to quic...@googlegroups.com
This  may be more of an ABCL question than a Quicklisp question I guess, but I haven't yet found a good place to ask ABCL questions of this type.
I'll post this in the common-lisp group too.

I have the following code in my SBCL and ABCL rc files for quicklisp:

#-quicklisp
(let ((quicklisp-init (merge-pathnames "quicklisp/setup.lisp"
                                       (user-homedir-pathname))))
  (when (probe-file quicklisp-init)
    (load quicklisp-init)))


It executes in negligible time in SBCL, but takes about 12-13 seconds every time in ABCL (beyond the prior 2 seconds for normal jvm/abcl startup time).

In both cases there's no obvious compilation or other stuff going on (as in, no output to console of things being compiled).

Any idea why it takes so long in ABCL?  

Thanks, and ABCL discussion forum pointers welcome.




Zach Beane

unread,
Nov 5, 2013, 8:28:50 AM11/5/13
to quic...@googlegroups.com
I'm not sure why it takes so long, sorry. I don't think that's typical,
but I could be mistaken. I don't use ABCL very much.

armedbe...@common-lisp.net is a good place for ABCL questions. I'm
not sure how you subscribe, but there are a lot of helpful ABCL hackers
answering questions there.

Zach

Mark Evenson

unread,
Nov 6, 2013, 5:58:31 AM11/6/13
to Armed Bear, quic...@googlegroups.com
On 05/11/13 1552 , Mark Evenson wrote:

>> Dave Tenny <dave....@gmail.com> writes:
>>
>>> This may be more of an ABCL question than a Quicklisp question I guess,
>>> but I haven't yet found a good place to ask ABCL questions of this type.
>>> I'll post this in the common-lisp group too.
>ring questions there.

> [�] Since Quicklisp is
> intimately connected to ASDF which in turn is wedded at the hip to CLOS,
> loading Quicklisp in `~/.abclrc` effectively means that there are no
> time savings incurred by the autoload mechanism.
>
> Note that I "believe" this to be the case, not having actually verified
> by appropriate profiling, which would probably be easy to do by some
> combination of setting the [`abcl.autoload.verbose`][1]: Java property
> to collect various profiles of with/without Quicklisp/ASDF.
>
> [1]: http://abcl.org/trac/wiki/AbclJavaProperties

A retraction after a little further investigation: my hunch of long
startup times for for ABCL with Quicklisp "because of the autoload
mechanism" is mostly bogus. This can be shown by the difference of
CL:TIME profiles of loading Quicklisp with ASDF previous loaded:

tethys:~/work/asdf$ abcl --noinform --noinit --eval '(require :asdf)'
--eval '(time (load "~/quicklisp/setup.lisp"))'
8.73 seconds real time
588035 cons cells

and without:

tethys:~/work/asdf$ abcl --noinform --noinit --eval '(time (load
"~/quicklisp/setup.lisp"))'
12.143 seconds real time
1044558 cons cells

The actual problem seems to lie more in how long it takes ABCL to load
an ASDF system. Some of this time seems to come from the autoload of
the compiler, but the majority of time seems to be from simply loading
the discrete FASLs on the filesystem. We'll look into further
optimization strategies for improving load times.

Followups to armedbear-devel@ please: we return you to your regularly
scheduled Quicklisp goodness.

--
"A screaming comes across the sky. It has happened before, but there
is nothing to compare to it now."

Mark Evenson

unread,
Nov 5, 2013, 9:52:01 AM11/5/13
to quic...@googlegroups.com, Armed Bear
Unfortunately, I believe that the long startup time for Quicklisp in
ABCL is typical In order to save on raw startup time, the ABCL
implementation has an autoload mechanism by which the compilation unit
("file") containing a given function is not loaded until first one is
executed. Among other things, this means that we don't have to load
CLOS to get to the bare "CL-USER>" REPL prompt. Since Quicklisp is
intimately connected to ASDF which in turn is wedded at the hip to CLOS,
loading Quicklisp in `~/.abclrc` effectively means that there are no
time savings incurred by the autoload mechanism.

Note that I "believe" this to be the case, not having actually verified
by appropriate profiling, which would probably be easy to do by some
combination of setting the [`abcl.autoload.verbose`][1]: Java property
to collect various profiles of with/without Quicklisp/ASDF.

[1]: http://abcl.org/trac/wiki/AbclJavaProperties

We would welcome any suggestions for strategies to decrease our this time.
Reply all
Reply to author
Forward
0 new messages