Since I didn't see a response I will "take a swing" and throw out a couple of general follow-up questions...

1. why load so much data into an executable image?

2. why could the data not be dumped/stored in one or more .lisp files using some sort of smart pretty-printer, then pre-compile to a .fasl and distribute them alongside your executable, and then load the .fasl's & piece them together in memory at runtime?

If your data is horribly complex beyond just being big lists-of-lists-of-atoms, then you might need to flatten it... or you may need a really smart pretty printer and/or serialization/deserialization mechanism which my be a drawback to this approach admittedly.  I don't know what your data looks like, so it is hard to say.

The .fasl approach would also allow you to show a "loading data, please wait... this could take a while" message to the user if need be.

I guess I have never been a big fan of "load GB of goo into memory and save it to an executable approach"... since having multi-GB executable goes against my better sensibilities in terms of where to blur the line between code and data.  GB of preloaded data structure feels like data more than code to me.  That is my opinion however, for what it is worth :-)

Loading a fasl should not be much slower than loading the data from the executable image file I would imagine since it is pre-compiled code, but would need to try it to be sure.

; -- This is data1.lisp
; Define a global data structure
(defvar *data1*
 '(("a" (1 2))
   ("b" (3 4))
   ("c" (5 6))))
; -- end of data1.lisp

$ sbcl
* (compile-file "./data1.lisp")

Then at runtime: (load "./data1.fasl") after which you can access *data1*.  If you have multiple data files you could have a cascade-loading approach that then stuffs them all into one "master list" of some sort.

May also want to use packages to compartmentalize the "global" data if you don't want them to clutter cl-user or whatever package you are using for your code.

[Sbcl-help] Large Executable Cores Crashing on Startup - Sometimes
From: Burton Samograd <burton.samograd@gm...> - 2012-07-07 20:34