timholy / SnoopCompile.jl

Provide insights about latency (TTFX) for Julia packages
https://timholy.github.io/SnoopCompile.jl/dev/
Other
309 stars 48 forks source link

A lazier approach to precompilation #358

Closed untoreh closed 1 year ago

untoreh commented 1 year ago

Having dedicated precompile statements is fine for libraries, but not ideal for applications. What if function calls could be precompiled when they are called? "just in time precompilation"

Let's say there is a macro

@precompile_on_demand f(...)

That wraps the call in a separate module, precompiles that module, and replaces the call with the call from that module?

module PrecompMod
@precompile_all_calls f(...)
end
using .PrecompMod
PrecompMod.f(...)

maybe this can be done with Cassette?

timholy commented 1 year ago

I'm not certain I understand the points you are making.

Having dedicated precompile statements is fine for libraries, but not ideal for applications.

Are you talking about workload-based precompilation with SnoopPrecompile, or explicit precompile(f, argtypes) directives? And what specifically about applications makes this harder? Are you aware of https://julialang.github.io/Precompiler.jl/dev/#Tutorial:-local-%22Startup%22-packages (which is written for what will become SnoopPrecompile's successor, but fully applicable if you replace names like Precompiler in those docs with their current SnoopPrecompile counterparts).

What if function calls could be precompiled when they are called? "just in time precompilation"

They are already: any time you execute foo(args...), if this combination of types has never been compiled before, it will be compiled before it runs. But you have to wait until compilation finishes before the function starts running. Are you proposing something that would be done ahead of time?

untoreh commented 1 year ago

Are you talking about workload-based precompilation with SnoopPrecompile, or explicit precompile(f, argtypes) directives?

I am thinking of, for example, cli applications where there might be many combinations of flags, and maybe precompiling all the combinations would be too much

Are you proposing something that would be done ahead of time?

Like running a cli command with some flags. The next time it runs with those same flags it would use a precompiled version, so I am referring to persistent precompilation like it is done for packages, but now that I think about it precompilation happens at package level, not a module level, so what I wrote is gibberish :)

timholy commented 1 year ago

Gotcha. I think for a cli application, one would do the flag-processing at runtime, so I think it would probably be quite feasible to compile the code that implements the different options. (You only need one compile target, not one target per combination of flags.)

I'll close this, but if you play with this and come up with a concrete example of something that isn't working as you might hope, happy to talk about fixes!