-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
[REF-2122] Opt-in multiprocess compile #2838
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
good idea keeping behind a flag - super snappy for me with it enabled
Control whether multiprocessing is used and the number of processes or threads that should be used. This will allow users to opt-in to the new, potentially hazardous, multiprocessing mode, which results in much faster compiles, but has already been reverted 4 times. Lets leave the code in this time, but use the thread pool executor by default. Limiting the number of threads or processes to 1 can also aid in debugging issues that arise during compile time.
8a6064b
to
51bf447
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Works well for me - in the future we may want to break up the compile
method as it's getting quite huge
Personally I'd like to see if more modularized and pluggable, at least the parts we parallelize, because obviously the order does not matter for those. |
Based on #2810
Pass the environment variable
REFLEX_COMPILE_PROCESSES=0
to enable multiprocessing compilation engine. Pass a number other than zero to control the number of processes to spawn.It's also possible to set
REFLEX_COMPILE_THREADS=X
where X is the number of threads to use, and zero (the default) means automatic.The default behavior here is to continue using the ThreadPoolExecutor as the default engine. It's not as fast as multiprocessing, but since 4 previous revisions of this code have been reverted, I'm sticking with a safe default until we can get more real world testing... but no one is going to test it in a side branch, so we need to get it into main and enable it during out development processes to try to tease out any issues.
Exposing the controls this way also allows us to more easily tune and tweak the implementation without having to edit the code directly.