freenode/#clasp - IRC Chatlog
Search
20:28:30
drmeister
Hey stassats - I added the ability for clasp to save and load snapshots of memory.
20:29:37
drmeister
Yeah - from 46.4 seconds on the mac (for our most complicated image) down to 6.7 seconds.
20:30:22
drmeister
I hope to do better in the future - I'm talking with an engineer at Apple who wants to optimize things. Most of the 6.7 seconds is linking thousands of object files.
20:30:51
drmeister
It doesn't run any code on startup. It's all llvm dynamic linking of object files.
20:32:26
drmeister
They are generated by our parallel compiler - it generates one object file per top-level form.
20:34:30
drmeister
I did some profiling of the startup - it's mostly in llvm where the time is being spent - I'll do some more now that I have it working on macOS again.
20:35:04
drmeister
I think it's probably more the number of symbols that need to be dealt with rather than the number of object files. But using the serial compiler would test that.
20:35:52
drmeister
Yes - that was the challenge. I'm also doing this with the boehm GC - with no cooperation other than the ability to walk objects in memory.
20:36:42
drmeister
I can also link a new executable that contains the snapshot embedded within it. So a single executable that contains everything needed to run the lisp session.
20:37:44
drmeister
I needed to do this because 46 seconds startup for our jupyterlab kernel was unacceptable. 6.7 seconds is still painful - but not as bad as 46 seconds.
21:29:15
drmeister
If I use compile-file-serial to build the quicklisp code the startup time drops to 5.1 seconds.
2:37:40
Bike
https://llvm.org/doxygen/classllvm_1_1PointerUnion.html til llvm uses tagged pointers internally
2:40:32
drmeister
I'm trying to come up with a way of generating a list of symbols to export automatically from just the object files.
2:58:50
drmeister
I'm going to have a weird symbol file that I'll concat into the symbol file I construct by scraping object files. We can look through it and remove anything that we don't need.
2:59:58
drmeister
I've got code that generates an 85,747 symbol file that is almost a superset of the 12,000 symbol file except for a few weird symbols like _cc_throw.
3:02:10
drmeister
Ah - they might be there but not exported. But my handcrafted symbol file might have picked them up - not because we need them exported - but they just got picked up somehow.