Choosing what to precompile as a package author

General Usage
1

The native code caching in 1.9 is amazing, but as a package author its sometimes hard to navigate the precompile-time / run-time tradeoff and decide what to precompile. In my case if I precompile “pretty much everything one might need” it takes a pretty painful 5min (but then ofc TTFX is amazing). But in certain contexts alot of that may be overkill. For example, if I myself am doing some active development requiring restarts, I might want nothing precompiled, or if eg my package is being used in a project that knows it will do Float32 but never Float64, they could halve the precompile time.

Right now I’m thinking I have a Preferences.jl preference in my package which specifies how much (or how little) to precompile. The advantages I see is that it gives the user some control, and by keeping the precompile directives in my package (rather than e.g. an enclosing monorepo), it will cut down some on the repetition of that 5min.

I’m wondering if this sounds like a reasonable thing to do? Or if anyone else has faced this and has thoughts on what works well and what doesnt? Thanks.

2 Likes
2

Rather than use Preferences to control precompilation, would it work to document for users how to create their own custom Startup.jl packages? Question about using SnoopPrecompile - #9 by tim.holy

1 Like
3

Thanks, yea, that’s definitely the most flexible option I suppose, but in terms of imagining writing the README, for my approach its something like “run MyPackage.set_preference!("precompile", "Float32, Float64")” and select what you want, whereas for that theyre "generate a package in environment X, open the file, edit it to contain particular code Y, remember to import your package), it seems a fair bit more complex.

4

Nothing wrong with using Preferences for this purpose. (Much better than an ENV variable.)

1 Like