> What about having one core with all your scripts? Or starting your
> Lisp at boot time with all the fasl files loaded.
>
> Andras
The scripts are in constant development. Having to dump core everytime I
make a change doesn't seem to me to be a very clean solution. I'm using it
for "scripting" after all. So I'd like something quick to write and run
like perl or python, not something that I have to recompile every time I
make a small change like in C. Loading .fasl files achieves this end but
is still slow. So I'm just curious; why do .fasl files take so long to
load? I'm not intending to complain about it; I'm simply stating why it
would be useful to me if they loaded faster and asking what's stopping
that from being the case to satisfy my curiousity.
The idea of having one core started at boot is something I've used for
another project, but these are scripts. Somehow I have to be able to call
those scripts from other scripts or from the command line. So that would
need some kind of socket interface and client executable to call the
scripts with. That's too much work for just a bunch of small hacks (though
recent changes to detachtty probably make this more plausible).
Robert Marlow wrote:
>>What about having one core with all your scripts? Or starting your
>>Lisp at boot time with all the fasl files loaded.
>>
>>Andras
>
> The scripts are in constant development. Having to dump core everytime I
> make a change doesn't seem to me to be a very clean solution. I'm using it
> for "scripting" after all. So I'd like something quick to write and run
> like perl or python, not something that I have to recompile every time I
> make a small change like in C. Loading .fasl files achieves this end but
> is still slow. So I'm just curious; why do .fasl files take so long to
> load? I'm not intending to complain about it; I'm simply stating why it
> would be useful to me if they loaded faster and asking what's stopping
> that from being the case to satisfy my curiousity.
Why don't you use a different CL implementation that is more responsive
for your scripting needs. I think that clisp is quite suitable here, right?
Pascal
--
2nd European Lisp and Scheme Workshop
July 26 - Glasgow, Scotland - co-located with ECOOP 2005
http://lisp-ecoop05.bknr.net/
On Wed, 25 May 2005 09:42:31 +0200, Pascal Costanza wrote:
> Robert Marlow wrote:
>> The scripts are in constant development. Having to dump core everytime I
>> make a change doesn't seem to me to be a very clean solution. I'm using
>> it for "scripting" after all. So I'd like something quick to write and
>> run like perl or python, not something that I have to recompile every
>> time I make a small change like in C. Loading .fasl files achieves this
>> end but is still slow. So I'm just curious; why do .fasl files take so
>> long to load? I'm not intending to complain about it; I'm simply stating
>> why it would be useful to me if they loaded faster and asking what's
>> stopping that from being the case to satisfy my curiousity.
>
> Why don't you use a different CL implementation that is more responsive
> for your scripting needs. I think that clisp is quite suitable here,
> right?
Maybe it is, maybe it isn't. What I'm asking is why .fasl files tend to
load slowly.
Robert Marlow wrote:
> On Wed, 25 May 2005 09:42:31 +0200, Pascal Costanza wrote:
>
>
>>Robert Marlow wrote:
>>
>>>The scripts are in constant development. Having to dump core everytime I
>>>make a change doesn't seem to me to be a very clean solution. I'm using
>>>it for "scripting" after all. So I'd like something quick to write and
>>>run like perl or python, not something that I have to recompile every
>>>time I make a small change like in C. Loading .fasl files achieves this
>>>end but is still slow. So I'm just curious; why do .fasl files take so
>>>long to load? I'm not intending to complain about it; I'm simply stating
>>>why it would be useful to me if they loaded faster and asking what's
>>>stopping that from being the case to satisfy my curiousity.
>>
>>Why don't you use a different CL implementation that is more responsive
>>for your scripting needs. I think that clisp is quite suitable here,
>>right?
>
> Maybe it is, maybe it isn't. What I'm asking is why .fasl files tend to
> load slowly.
They don't load slowly in all implementations, at least not in my
experience. When I load my ContextL package, I get the following
numbers. (All called with (time (asdf:oos 'asdf:load-op :contextl))), in
fresh images with everything already compiled.
Allegro 6.2:
; cpu time (non-gc) 240 msec user, 30 msec system
; cpu time (gc) 80 msec user, 0 msec system
; cpu time (total) 320 msec user, 30 msec system
; real time 628 msec
; space allocation:
; 41,272 cons cells, 1,469,672 other bytes, 0 static bytes
clisp 2.33:
Real time: 1.183547 sec.
Run time: 0.629509 sec.
Space: 3072320 Bytes
GC: 3, GC time: 0.115105 sec.
LispWorks 4.4:
user time = 0.743
system time = 0.051
Elapsed time = 0:00:02
Allocation = 15852320 bytes
(I had to type :c to continue after a stack overflow in between here.)
openmcl 0.14.3:
(ASDF:OOS 'ASDF:LOAD-OP :CONTEXTL) took 229 milliseconds (0.229 seconds)
to run.
Of that, 116 milliseconds (0.116 seconds) were spent in user mode
37 milliseconds (0.037 seconds) were spent in system mode
76 milliseconds (0.076 seconds) were spent executing other OS
processes.
534,112 bytes of memory allocated.
sbcl 0.9.0
Evaluation took:
4.734 seconds of real time
3.125636 seconds of user run time
0.250086 seconds of system run time
0 page faults and
32,919,248 bytes consed.
...all on Mac OS X 10.4.1.
Pascal
--
2nd European Lisp and Scheme Workshop
July 26 - Glasgow, Scotland - co-located with ECOOP 2005
http://lisp-ecoop05.bknr.net/
Pascal Costanza <··@p-cos.net> writes:
> Robert Marlow wrote:
> > On Wed, 25 May 2005 09:42:31 +0200, Pascal Costanza wrote:
> >
>
> >>Robert Marlow wrote:
> >>
> >>>The scripts are in constant development. Having to dump core everytime I
> >>>make a change doesn't seem to me to be a very clean solution. I'm using
> >>>it for "scripting" after all. So I'd like something quick to write and
> >>>run like perl or python, not something that I have to recompile every
> >>>time I make a small change like in C. Loading .fasl files achieves this
> >>>end but is still slow. So I'm just curious; why do .fasl files take so
> >>>long to load? I'm not intending to complain about it; I'm simply stating
> >>>why it would be useful to me if they loaded faster and asking what's
> >>>stopping that from being the case to satisfy my curiousity.
> >>
> >>Why don't you use a different CL implementation that is more responsive
> >>for your scripting needs. I think that clisp is quite suitable here,
> >>right?
> > Maybe it is, maybe it isn't. What I'm asking is why .fasl files tend
> > to
>
> > load slowly.
>
> They don't load slowly in all implementations, at least not in my
> experience. When I load my ContextL package, I get the following
> numbers. (All called with (time (asdf:oos 'asdf:load-op :contextl))),
> in fresh images with everything already compiled.
>
>
> Allegro 6.2:
>
> ; cpu time (non-gc) 240 msec user, 30 msec system
> ; cpu time (gc) 80 msec user, 0 msec system
> ; cpu time (total) 320 msec user, 30 msec system
> ; real time 628 msec
> ; space allocation:
> ; 41,272 cons cells, 1,469,672 other bytes, 0 static bytes
I can't speak for the other lisps, but it may be possible to
load these even faster, depending on several "*LOAD-" variables -
excl:*load-xref-info*, excl:*load-local-names-info*,
excl:*load-xref-info*, excl:*load-source-file-info*, and
excl:*load-documentation* - if these are true and if the
corresponding info is in the fasl file, then setting them to
nil will reduce the consing and the time it takes to load
the fasl file. Of course, it is even better to generate the
fasl file stripped of this info in the first place: for the
"*LOAD-...-INFO*" variables, the corresponding "*RECORD-...-INFO*"
variables control this. Such a fasl-loading optimization is
useful in a scripting environment, where the debug info isn't
necessarily needed (since the scripts themselves tend to be
simple relative to a larger, more involved program), so it makes
sense to turn all of this stuff off when running scripts.
And we should know; we try to "eat our own dog food" when it
comes to scripting; the earliest example was in the generate-application
and build-lisp-image scripts, we got away from shell-script based
building around the time that Allegro CL 5.0 cam along, if I
remember correctly.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
On Wed, 25 May 2005 10:13:37 +0200, Pascal Costanza wrote:
> They don't load slowly in all implementations, at least not in my
> experience. When I load my ContextL package, I get the following numbers.
> (All called with (time (asdf:oos 'asdf:load-op :contextl))), in fresh
> images with everything already compiled.
>
<SNIP>
Ah, thanks. Those statistics are comforting. At least that confirms that
loading .fasls is not necessarily slow in common lisp. I couldn't think of
any reason why it would need to be.
I'll go ask sbcl-devel why it's slow for that implementation then. I'd be
interested in speeding it up if it's plausible.
Robert Marlow <··········@bobturf.org> writes:
> Maybe it is, maybe it isn't. What I'm asking is why .fasl files tend to
> load slowly.
If I recall correctly, this was discussed some time ago in the SBCL
mailing list in the context of this Common Lisp implementation.
Paolo
--
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
Recommended Common Lisp libraries/tools (see also http://clrfi.alu.org):
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- UFFI: Foreign Function Interface
Robert Marlow <··········@bobturf.org> writes:
>> What about having one core with all your scripts? Or starting your
>> Lisp at boot time with all the fasl files loaded.
>>
>> Andras
>
> The scripts are in constant development. Having to dump core everytime I
> make a change doesn't seem to me to be a very clean solution. I'm using it
> for "scripting" after all. So I'd like something quick to write and run
> like perl or python, not something that I have to recompile every time I
> make a small change like in C.
Misconception. Dumping a lisp image has nothing to do with compiling.
It's just writting the file.
It's no more complicated than saving a buffer from emacs into your script file.
(ext:saveinitmem "/usr/local/bin/script.mem.gz" :quiet t
:init-function (function dispatch-script))
If you work in emacs, you can even bind locally C-x C-s to an emacs command:
(defun save-image ()
(interactive "P")
let ((savesexp
(format "(ext:saveinitmem \"%s.mem.gz\" :quiet t
:init-function (function dispatch-script))"
(if current-prefix-arg
(read-from-minibuffer "Script path: ")
"/usr/local/bin/script"))))
(process-send-string (get-buffer-process
(or inferior-lisp-buffer (current-buffer)))
savesexp))
(add-hook 'inferior-lisp-mode-hook
(lambda () (local-set-key "C-xC-s" 'save-image)))
or something like that.
--
__Pascal Bourguignon__ http://www.informatimago.com/
In deep sleep hear sound,
Cat vomit hairball somewhere.
Will find in morning.