Skip to content
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

Merged
merged 6 commits into from
Mar 16, 2024

Conversation

masenf
Copy link
Collaborator

@masenf masenf commented Mar 12, 2024

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.

Copy link

linear bot commented Mar 12, 2024

@masenf masenf changed the base branch from main to masenf/custom-component-state March 12, 2024 00:49
picklelo
picklelo previously approved these changes Mar 13, 2024
Copy link
Contributor

@picklelo picklelo left a 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

Base automatically changed from masenf/custom-component-state to main March 13, 2024 20:41
@masenf masenf dismissed picklelo’s stale review March 13, 2024 20:41

The base branch was changed.

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.
@masenf masenf force-pushed the masenf/multiprocess-compile-try-again branch from 8a6064b to 51bf447 Compare March 13, 2024 20:45
Copy link
Contributor

@picklelo picklelo left a 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

@masenf
Copy link
Collaborator Author

masenf commented Mar 16, 2024

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.

@masenf masenf merged commit ee1ff7f into main Mar 16, 2024
62 checks passed
@masenf masenf deleted the masenf/multiprocess-compile-try-again branch March 16, 2024 00:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants