Cache compiled webppl header

[stuhlmueller]

Before I merged the stochastic-dependence-analysis branch, we were caching the compiled webppl header. After the merge in d94e1642ec7f7f24ff68ef62d17262fa969c7ad6, this is no longer the case. I didn't port the previous solution to caching the compiled header, since it wasn't ideal in the first place. A better solution will generate the header once when some install command is run, and subsequently only read it in from a file.

[null-a]

Note that this gets trickier if we allow user macros to transform the header.

[stuhlmueller]

I'll take that as another (not very strong on its own) argument that user macros shouldn't transform the header.

[null-a]

Something else to consider is that fact that we've since added the freevars transform, which is applied to the header conditionally, depending on whether IncrementalMH is used. (There may be more of this kind of thing in the future. #136)

Somewhat related: The call to sweet.loadModule(<contents of headerMacros.sjs>) (here) takes around 0.6s on my machine. (Versus 0.35s for the call to compile.) headerMacros.sjs has very little in it, most of the time here is some kind of overhead which is incurred on the first call to loadModule. HMC adds a second call to loadModule which takes around 0.3s, assuming the overhead happened in an earlier call. So, it looks like we're spending quite a bit more time loading macro modules than compiling, perhaps this can be cached too.

[stuhlmueller]

That's a lot of time spent loading macros! Good to know. As a first step, would there be any problem with memoizing sweet.loadModule using a non-cps version of cache?

[null-a]

would there be any problem with memoizing sweet.loadModule using a non-cps version of cache?

I don't think so. I was going to think about doing something which would help in Node too, but that needs some thought. This only helps the browser (right?), but it's so simple that it seems worth doing. I'll take a look.

[null-a]

would there be any problem with memoizing sweet.loadModule using a non-cps version of cache?

This only helps the browser (right?),

Looking at it, I don't think it helps in the browser either. Memoizing loadModule won't speed up the first call of course (which takes ~500ms), and subsequent calls are already fast in the browser (~20ms). This is presumably because the overhead I mentioned has been incurred during the first call.

[null-a]

Looking at it, I don't think it helps in the browser either.

For future reference, we don't need to worry about making this change. In the browser we now (#285) call loadModule only once on the contents of each .sjs macro file, and as suggested earlier it wouldn't help in Node.