-
Notifications
You must be signed in to change notification settings - Fork 49
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
A lazier approach to precompilation #358
Comments
I'm not certain I understand the points you are making.
Are you talking about workload-based precompilation with SnoopPrecompile, or explicit
They are already: any time you execute |
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
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 :) |
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! |
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
That wraps the call in a separate module, precompiles that module, and replaces the call with the call from that module?
maybe this can be done with Cassette?
The text was updated successfully, but these errors were encountered: