-
Notifications
You must be signed in to change notification settings - Fork 52
Add SnoopPrecompile package #282
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
Conversation
This small package makes it easy to exhaustively precompile on
Julia 1.8 and higher. In brief, your package should look like
```
module MyPackage
using SnoopPrecompile
# method definitions etc
let
@precompile_calls begin
# code you want precompiled
end
end
end # module MyPackage
```
There are also facilities for "setup" code, see the documentation
for details.
|
CC @ChrisRackauckas, @SimonDanisch, @rikhuijzer, @LilithHafner, @IanButterworth. This gets both the inferrable and runtime-dispatched calls. It also bundles in the |
Codecov Report
@@ Coverage Diff @@
## master #282 +/- ##
==========================================
- Coverage 86.44% 82.52% -3.93%
==========================================
Files 16 17 +1
Lines 2022 1946 -76
==========================================
- Hits 1748 1606 -142
- Misses 274 340 +66
Continue to review full report at Codecov.
|
|
So basically this approach falls in between running a workload and calling Why is |
let
@precompile_calls begin
# execute the code you want precompiled
end
endWouldn't it be easier for the macro to introduce the let block? |
More precisely, it supplements "running a workload" with interception of runtime-dispatched calls. Even on Julia 1.8, those are not precompiled if the method called belongs to another package. Precompilation requires a chain of inference back to the package being precompiled, unless there's an explicit
it does cause the same side effects (the workload actually runs)
exactly.
No major reason but there's no disadvantage. (It does have code in common with SnoopCompileCore so it may be slightly easier to maintain this way.) It will be an independently-registered package in its own right. |
Handling @precompile_calls :setup begin
vars = ...
@precompile_calls begin
somecall(vars...)
end
endsince |
|
Using that approach, Another approach uses only a single macro call, following the style of @precompile_calls begin
somecalls(vars...)
end setup = (vars = ...) |
Check, so that is done by the For the macro name |
It does 🙂 . I'm |
|
But of course happy to accept other names, given that it's obviously confusing! |
That is 100% obvious now that you say it, but I also didn't realize that precompile was a verb in that context. |
|
If a name change doesn't seem in the offing, clearly it needs at least a docstring. |
|
I think I've addressed most of the feedback. Some comments:
|
|
I'm beginning to lean towards |
|
+1 for |
|
How about |
|
I went with |
This small package makes it easy to exhaustively precompile on
Julia 1.8 and higher. In brief, your package should look like
There are also facilities for "setup" code, see the documentation
for details.