Paul Khuong <pvk@...> writes:
> On 2012-11-19, at 10:04 AM, Faré <fahree@...> wrote:
>> Dear SBCL hackers,
>> is there a way, beside actually calling the function, to force SBCL to
>> pre-compile the bits of code associated with method definitions?
>> Currently, we have a significant pause during our first request while
>> SBCL spends time in the compiler to do something compiling methods.
> In the general case (with degenerate enough class structure and method
> specialisations), I don't think it's practical. For a lot of practical
> cases, however, I believe it's possible to design something that
> degrades as gracefully as the current scheme.
Bah, and I just sent Faré an implementation of precompiling for all
possible combinations of arguments, thinking "this might be material for
a blog post! That counts as publication, right?"
> What's the shape of the inheritance graph like? How many methods are
> there per gf, and how are they specialised? Any fancy method
> combination (less important than it might seem, because the MOP is
> already twisted for arbitrary combinations)?
I'm not sure that method combination is relevant, is it? Or if it is
it's truly an edge case. What might be of immediate practical interest
too is a simple function that introspects the current state of a gf's
cache / dfun state and emits code that reconstructs it, so that once
you've warmed up your application by running it on some representative
data, you can compile a file containing e.g.
(precompile-gfs #'foo #'bar)
and the resulting fasl when loaded will populate the caches of #'foo and
#'bar to be what they were when the form was compiled.