[Ecls-list] Startup time

[Waldek Hebisch]

Currently, large program compiled by ECL start up visibly slower
than using other Lisps.  My estimate is that during FriCAS bootstrap
main FriCAS binary is started up about 1000 times, each startup taking
about 1s, which adds up to rather substantial 1000s.  Also during
testsuite run FriCAS binary is invoked about 150 times, this time
each invocation costs about 2.8s, for total of order 420s.  Below
some measurement trying to find out reasons.


One case is ECL compiler:

$ (export LD_LIBRARY_PATH=/var/tmp/hebisch/usr/lib; AXIOM=/var/tmp/hebisch/axp5/ax-build1/target/x86_64-unknown-linux; echo "(time (require 'cmp)) (quit)" | time /var/tmp/hebisch/usr/bin/ecl)
ECL (Embeddable Common-Lisp) 0.9j (CVS 2008-05-14 13:43)
Copyright (C) 1984 Taiichi Yuasa and Masami Hagiya
Copyright (C) 1993 Giuseppe Attardi
Copyright (C) 2000 Juan J. Garcia-Ripoll
ECL is free software, and you are welcome to redistribute it
under certain conditions; see file 'Copyright' for details.
Type :h for Help.  Top level.
> ;;; Loading #P"/var/tmp/hebisch/usr/lib/ecl/cmp.fas"
;;; Loading #P"/var/tmp/hebisch/usr/lib/ecl/sysfun.lsp"
real time : 0.257 secs
run time  : 0.220 secs
gc count  : 7 times
consed    : 9652984 bytes
("CMP")
> 0.43user 0.00system 0:00.48elapsed 88%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+1560minor)pagefaults 0swaps

Another reason is that loading large number of fasls takes a lot of time.
>From FriCAS prompt we load 1090 fasls:

(1) -> )lisp (time (dolist (el (directory "ax-build1/target/x86_64-unknown-linux/algebra/*.fas")) (load el)))
real time : 42.731 secs
run time  : 38.810 secs
gc count  : 1091 times
consed    : 56051704 bytes
Value = NIL
(1) -> )lisp (time (si::gc t))
real time : 0.047 secs
run time  : 0.050 secs
gc count  : 2 times
consed    : 0 bytes
Value = NIL
(1) -> )lisp (time (si::gc nil))
real time : 0.047 secs
run time  : 0.050 secs
gc count  : 2 times
consed    : 0 bytes
Value = NIL

So, it seems that loading each fasl triggers garbage collection,
and those collections are responsible for substantial part
of the load time.  Is there a way to make garbage collection
more lazy?

-- 
                              Waldek Hebisch
hebisch at math.uni.wroc.pl