-
-
Notifications
You must be signed in to change notification settings - Fork 5.7k
precompile_utils: Don't auto-enqueue macro
methods for pre-compilation
#57833
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
precompile_utils: Don't auto-enqueue macro
methods for pre-compilation
#57833
Conversation
macro
methods for pre-compilationmacro
methods for pre-compilation
@JeffBezanson What do you think about deleting the auto- Does it serve any purpose if we are generally not compiling this code anyways? |
Does these mean macro methods don't get precompiled at all? Isn't that desirable to avoid having to precompile them at every first use? |
Yes let's try removing the inserted |
macros do not get used at runtime, so including them in the precompile files is (mostly) a waste of space (as is specializing them) |
OK, it's certainly possible that no noticeable latency improvements come from precompiling macros. |
They get used at runtime in scripts (notebooks etc) and by other packages during precompile time. I don't see why it doesn't make sense to compile e.g. the JuMP macros once instead of adding latency to every single script a user wants to run with it. |
Would it make sense to resolve the tradeoff by:
|
There's not much purpose of this de-specialization, since macros are generally excluded from inference / compilation anyway (except for JuliaLang#57833 which was a bug) Since our AST is already relatively homogeneous, it's not clear that we gained much by this de-specialization when it was used. Arbitrarily de-specializing a function also often leads to bad (wide) edges in inference etc., causing frequent invalidations.
There's not much purpose of this de-specialization, since macros are generally excluded from inference / compilation anyway (except for JuliaLang#57833 which was a bug) Since our AST is already relatively homogeneous, it's not clear that we gained much by this de-specialization when it was used. Arbitrarily de-specializing a function also often leads to bad (wide) edges in inference etc., causing frequent invalidations.
There's not much purpose of this de-specialization, since macros are generally excluded from inference / compilation anyway (except for JuliaLang#57833 which was a bug) Since our AST is already relatively homogeneous, it's not clear that we gained much by this de-specialization when it was used. Arbitrarily de-specializing a function also often leads to bad (wide) edges in inference etc., causing frequent invalidations.
Despite disabling the runtime from compiling `macro` functions in `gf.c`, the pre-compilation code was adding macro code anyway to the workqueue.
511502c
to
1a91678
Compare
Despite disabling these from being compiled in
gf.c
for dynamic invocations, the pre-compilation code was addingmacro
Methods anyway to the workqueue.Replaces #57782