Add mechanism to disable creating new worlds #56639
Conversation
vtjnash
force-pushed
the
jn/disable-new-worlds
branch
from
4fb87a4
to
500fe58
Compare
As a performance optimization, when you are certain only to run all
remaining code in a fixed world (e.g. not even eval a new closure or
comprehension), such as when all code is defined in a system image and
not being used interactively, you can put a call to:
Base.Experimental.disable_new_worlds()
Which will enable performance optimizations around avoiding tracking
backedges and invalidations.
vtjnash
force-pushed
the
jn/disable-new-worlds
branch
from
500fe58
to
aaaba65
Compare
| Base.Experimental.disable_new_worlds() | ||
| Mark that no new worlds (methods additions, deletions, etc) are permitted to be | ||
| created, allowing for greater performance and slightly lower memory usage by |
There was a problem hiding this comment.
Performance here can be elaborated a bit on here I think. Presumably your for loops won't run faster. This has mostly to do with package loading?
There was a problem hiding this comment.
| created, allowing for greater performance and slightly lower memory usage by | |
| created, allowing for lower latencies and slightly lower memory usage by |
There was a problem hiding this comment.
Okay, but when do you want to use this? This should have a description of a use case I feel.
|
This also means that you can't load any more code either, is that right? Folks may not think of |
| """ | ||
| Base.Experimental.disable_new_worlds() | ||
| Mark that no new worlds (methods additions, deletions, etc) are permitted to be |
There was a problem hiding this comment.
It's probably worth mentioning that this transition is permanent (if I understand correctly)
You currently can (though Keno might remove that soon), since defining code isn't a world operation, only adding methods, so the methods won't "take effect" but the loading itself will be successful. |
|
That's neat --- I suppose you could load and use a package that just defines some constants or something. But in practice of course that is not really a requirement in these cases AFAIK. |
| JL_DLLEXPORT void jl_disable_new_worlds(void) | ||
| { | ||
| if (jl_generating_output()) | ||
| jl_error("Disabling Method changes is not possible when generating output."); |
There was a problem hiding this comment.
But that's the only time I want to do it? 😂 How do you use this to generate "sealed" system images?
|
I think it's more confusing than it is neat. As a user, I would think it's a bug for Julia to claim to have loaded a package but not have applied its methods to the dispatch table |
|
Yeah no argument there; I don't think there is a real use case. (To clarify: I'm only referring to loading a package that defines methods, but ignoring those methods, as having no use case, not this PR generally.) |
As a performance optimization, when you are certain only to run all remaining code in a fixed world (e.g. not even eval a new closure or comprehension), such as when all code is defined in a system image and not being used interactively, you can put a call to:
Which will enable performance optimizations around avoiding tracking backedges and invalidations.