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
Use feature gate on parallelism #2959
Comments
I also have some confusions on #2825 (comment). While it said it has improved the performance overall, but it doesn't seems to be a suitable strategy for every situation. I don't know much about these two funcitons: oxc/crates/oxc_sourcemap/src/encode.rs Line 11 in 6561392
oxc/crates/oxc_sourcemap/src/encode.rs Line 74 in 6561392
But it seems that gonna be used in codegen. Then I realized these are gochas in logic
I suspect that's where it really improve the performance since the benchmark case used in #2825 (comment), which is a huge single chunk. If we have a case that generate so many mutiple small chunks, I wonder if it would be even a downside to the performance. However, it still show pentation on the case said #2825 (comment). So using feature gate might not enough, since we need dynamicly decide to use which method depend on the input. |
Let's either:
|
Let me try to find a way to benchmark this. On hold for now. |
Next release: Lines 43 to 44 in f6daf0b
|
Related:
Currernt
oxc_sourcemap
enable using rayon by default and it show improved performance said in #2825 (comment).However,
wasm
target doesn't have a good support in rayon. While rayon claims it's ok in some issues, but it's still quite frustrating to debug wasm + rayon. It would be helped if we could disable rayon using feature gate.Off the topic, Using feature gate on parallelism should be a principle that apply on all oxc crates that gonna exposed to users when introducing any parallelism in it.
The text was updated successfully, but these errors were encountered: