ANN: SnoopCompile for faster* package starts (*sometimes)

[Tim Holy]

Package precompilation/caching has greatly decreased the time needed to
packages, and for many of us is a favorite feature of julia 0.4. However, the
methods are typically cached in "generic" form and not specialized for every
possible combination of input types--consequently, actual usage requires
additional JIT-compilation steps. In practical experience, users of a large
package often see "startup" delays due to this need to JIT-compile the
functions in the package.

A new package SnoopCompile (https://github.com/timholy/SnoopCompile.jl) lets
you spy on the JIT-compiler and learn which functions & types it's compiling.
You can use the output of snooping to generate "precompile" directives that,
*in some cases*, decrease the time-to-first-results in a way that makes you
and/or your users happier. Since nothing ever comes for free, the expense is
longer building times when the package gets recompiled.

Using its standard "add precompile statements to the package source code"
mode, my track record so far is this:
- Gadfly & Compose: approximate halving of the time-to-first-visible-plot, and a
major reduction in the time needed for "runtests." This counts as a success
story.
- Iterators, DataArrays, CUDArt: the decrease in the time for "runtests" was
so modest, it wasn't really worth the effort. Not success stories.

In general I suspect that unless you're _really_ annoyed by the wait, you're
unlikely to get a lot of benefit from SnoopCompile. In this "standard" mode,
there's only so much it can do: we don't yet cache functions _across_ modules,
and in many packages these account for much of the startup lag.

I've also played with the more "aggressive" userimg.jl mode of the package
(see the README). With it I've been able to get a huge reduction in the time
needed to "runtests" for Images.jl, but I've also found problems with other
packages (Immerse) that I haven't yet spent the time to resolve. All in all I
am not a fan of the userimg.jl strategy, although it may make sense on a
server designed to support multiple users who never bugfix/improve their
packages. (Which never, ever applies to me personally :-).)

Enjoy,
--Tim

[Simon Danisch]

This is really great!! =)

Hope it'll work now, last time it segfaulted ;)

Thanks for this cool package!

Best,

Simon