-
-
Notifications
You must be signed in to change notification settings - Fork 26.9k
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
Remove thread-loader #5170
Remove thread-loader #5170
Conversation
After the cache is warm, it is possible for thread-loader to hurt speed
Do we have a clear idea of how much slower to cold build is in DEV or PROD? |
Per previous thread, prod build:
Size of application for scale: File sizes after gzip:
387.99 KB build/static/js/6.c8fffdff.chunk.js
286.88 KB build/static/js/5.057175f6.chunk.js
273.24 KB build/static/js/3.b13196e5.chunk.js
137.74 KB build/static/js/4.21e358cd.chunk.js
62.42 KB build/static/js/main.f8e7c995.chunk.js
21.19 KB build/static/css/3.07d6ad7e.chunk.css
1.06 KB build/static/css/main.6781b2da.chunk.css
210 B build/static/js/1.a6f64de4.chunk.js
145 B build/static/js/2.f7e78bdb.chunk.js |
That's for prod right? What about dev boot? Seems like snapshots need updating |
Dev, cold:
Dev, warm:
|
Cold dev boot suffers, but appear on-par/faster once cache is warm. I suspect our dev rebuilds will be much quicker with no |
Disabled broken test for now, will fix in follow up PR with the rest of output & tests. |
I'm in favour of this. Thread loader has ended up being the cause of a number of issues. |
We had an issue with worker-loader + thread-loader as well |
* Remove thread-loader After the cache is warm, it is possible for thread-loader to hurt speed * Disable babel output formatting
This was breaking our builds on CI environment. As CircleCI agents seemed to have 32 core CPUs but not enough RAM to handle the number of threads spawn by thread-loader. Glad it was removed. 👍 |
After the cache is warm, it is possible for thread-loader to hurt speed.
thread-loader also has leaky interaction with its workers, giving us some junk output here and there.
This will hurt cold boots/builds the most, but with our cache rules it should be very seldom someone needs to clear their cache (if ever).
Per #5138 (comment), future work is to write our own worker that handles caching and parallelization.
Fixes #5138