Peter, I didn't have time to thank you for your packaging. I have had a look at your recent work, and I'm very happy with it. For Cedilla, the current approach, while not perfect, is good enough. However, I do think that you folks (as well as upstream Common Lisp implementors) should be thinking about application delivery in the medium term.
- Using clc-require with a script (like it is done now) real 0m1.530s user 0m1.296s sys 0m0.160s
- Concatenated all the fasls (in the right order) into one: real 0m1.255s user 0m1.004s sys 0m0.048s
On my system, with a warm cache, clc-require: 0.384r, 0.349u + 0.031s Loading all the fasls one by one: 0.254r, 0.239u + 0.012s Loading the concatenated fasl: 0.268r, 0.247u + 0.016s Groff: 0.041r, 0.033u + 0.008s What's going on here? You've got to realise that Cedilla builds large hashtables at load time (see the generated file data.lisp). On your slowish system, building the hashtables appears to dominate the startup time; on my faster system, building the hashtables takes less time, and we're seeing the cost of the statting done by ASDF. (Of course, the building happens before dumping an image, which explains why dumping an image makes Cedilla so much faster. Any suggestions for making the loading of data.fas faster are welcome.) I think that Cedilla is slightly atypical; other programs will most likely not need to build such large hashtables at runtime. Thus, while the startup overhead is not a major problem for Cedilla, it is something that should be solved in the medium term. Oh, by the way, I'm not a great fan of dumped images; they use up loads of space, and prevent the Lisp runtime from being shared between Lisp processes. Thanks again for your work, Juliusz