-
Notifications
You must be signed in to change notification settings - Fork 622
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
Metro 0.45 / RN 0.57.0 - Initial builds 5-10x slower #253
Comments
Thanks for reporting the issue! A couple of questions: 1- Does this happen also when the local cache is full? e.g is the first build fast after restarting Metro? |
@rafeca thanks for the reply :)
|
@rafeca and in case it matters, the rough timings are like this in dev mode. Super slow start with a sudden burst in the last 10s. Previously it was a constant velocity 0-100% over about 20/30s.
|
Thanks for the detailed information! During startup Metro prints a message saying:
Once the dependency map gets initialized, the message becomes:
Can you check if the slowness is caused by the depdency graph loading? (this is the initialization of |
Also, regarding the cache issues that you mention, these are usually caused by external files that affect the transformation output (like In order to fix that, Metro has a config param called You can set it to any string and the whole transform cache of metro will get invalidated once this string changes. So, in order to use this to invalidate the cache once some files change in your repo change you can do something like: const crypto = require('crypto');
function getFileHash(file) {
return crypto
.createHash('sha1')
.update(fs.readFileSync(file))
.digest('hex');
}
const cacheKeyParts = [
'./package.json',
'./yarn.lock',
'./.babelrc',
/* ... */
].map(file => getFileHash(require.resolve(file)));
const cacheVersion = crypto
.createHash('sha1')
.update(cacheKeyParts.join('$'))
.digest('hex'); This will improve the developer experience quite a lot if your app is big, since transforming the whole app from scratch every time is painful. On production, I guess that is fine to keep the |
@rafeca Ahhh OK, thanks for that info, interesting as another part of my 'solution' for production builds was to write to a file One more piece of info - our
|
Ok, now we know that the slowdown comes from the transformation of files. Can you check if there may be any specific file that could be taking a long time to transform? You can do something like the following to hook into the Metro logger to print on the console the time that it takes to transform each file: const Metro = require('metro');
Metro.Logger.on('log', logEntry => {
if (
logEntry.action_name === 'Transforming file' &&
logEntry.action_phase === 'end'
) {
console.log(logEntry.file_name, logEntry.duration_ms);
}
}); You can add this logic in your |
Thanks @mjmasn alot for reported it in here. I has some deadline yesterday, so i couldn't check regularity notifications. Exactly like describle of mjmasn. The first bundling progress and after My Project using some large Realm file with total size about 100 MB. But it can load fine in older Metro |
@rafeca ok so in terms of timings:
Seems like images are taking ages, all are at least 50000ms and the highest is 143782ms. Not really sure why, isn't this basically just a hashing step given the images aren't included in the JS bundle? |
Are these times average per file? 😟 That's not expected at all... Usually transforming a file should take much less than a second... Do you have a custom |
@rafeca yeah per file 🙀 I've just created some test repos which show the issue one two brand new projects created with react-native init: https://github.com/mjmasn/FastMetro I pasted the timing logs from my machine in the READMEs to save you having to run them. As mentioned in the SlowMetro README, Our actual
|
wow, thanks a lot! these repro steps are really useful and I've been in fact able to reproduce the issue now. I was trying to repro using Investigating atm 🕵️♂️ |
Ok! found it! 😅 Somehow, when running the development server, the React Native CLI is not configuring Metro to use multiple workers to parallelize the transformation of files across CPUs. This is why build times is ~5-10X slower (depending on your number of cpus). I'm going to send a fix and release a patch version of Metro |
Until we have a fix you can workaround the issue by adding the $ node node_modules/react-native/local-cli/cli.js start --reset-cache --max-workers=6 |
@rafeca ah no way! I had actually noticed my PC was running really quiet (smallish form factor with super noisy fan makes it very noticeable when it's working hard) My colleagues have probably been enjoying the break from it 😂 Thank you for spending time looking into this one, much appreciated :) |
Perfectly. You made my day |
Summary: @public The React Native CLI is not passing the default `maxWorkers` param to Metro, making it run in a single thread and making the development process really slow. This fixes facebook/metro#253 Reviewed By: mjesun Differential Revision: D9915500 fbshipit-source-id: d15030af582e99fe20535c07e751cfe12e444f2f
Summary: @public The React Native CLI is not passing the default `maxWorkers` param to Metro, making it run in a single thread and making the development process really slow. This fixes facebook/metro#253 Reviewed By: mjesun Differential Revision: D9915500 fbshipit-source-id: d15030af582e99fe20535c07e751cfe12e444f2f
Taken from: facebook/react-native@202715c Summary: @public The React Native CLI is not passing the default `maxWorkers` param to Metro, making it run in a single thread and making the development process really slow. This fixes facebook/metro#253 Reviewed By: mjesun Differential Revision: D9915500 fbshipit-source-id: d15030af582e99fe20535c07e751cfe12e444f2f
Taken from: facebook/react-native@202715c Summary: @public The React Native CLI is not passing the default `maxWorkers` param to Metro, making it run in a single thread and making the development process really slow. This fixes facebook/metro#253 Reviewed By: mjesun Differential Revision: D9915500 fbshipit-source-id: d15030af582e99fe20535c07e751cfe12e444f2f
Taken from: facebook/react-native@202715c Summary: @public The React Native CLI is not passing the default `maxWorkers` param to Metro, making it run in a single thread and making the development process really slow. This fixes facebook/metro#253 Reviewed By: mjesun Differential Revision: D9915500 fbshipit-source-id: d15030af582e99fe20535c07e751cfe12e444f2f
Taken from: facebook/react-native@202715c Summary: @public The React Native CLI is not passing the default `maxWorkers` param to Metro, making it run in a single thread and making the development process really slow. This fixes facebook/metro#253 Reviewed By: mjesun Differential Revision: D9915500 fbshipit-source-id: d15030af582e99fe20535c07e751cfe12e444f2f
Taken from: facebook/react-native@202715c Summary: @public The React Native CLI is not passing the default `maxWorkers` param to Metro, making it run in a single thread and making the development process really slow. This fixes facebook/metro#253 Reviewed By: mjesun Differential Revision: D9915500 fbshipit-source-id: d15030af582e99fe20535c07e751cfe12e444f2f
Summary: @public The React Native CLI is not passing the default `maxWorkers` param to Metro, making it run in a single thread and making the development process really slow. This fixes facebook/metro#253 Reviewed By: mjesun Differential Revision: D9915500 fbshipit-source-id: d15030af582e99fe20535c07e751cfe12e444f2f
Do you want to request a feature or report a bug?
Bug (ported from RN repo as the issue reported by @Winglonelion was closed and locked there - facebook/react-native#21138)
What is the current behavior?
First build of react-native project takes ~3 mins (i.e. after running
yarn start
thenreact-native run-android
). Subsequent builds via Dev Menu -> Reload seem fine although maybe slower speed is less noticeable for incremental builds.If the current behavior is a bug, please provide the steps to reproduce and a minimal repository on GitHub that we can
yarn install
andyarn test
.It's probably not so noticable with small projects so bit hard to do a repro as our production app is not open-source. But building any project with RN 0.56.1 and then 0.57.0 should show a difference.
What is the expected behavior?
It used to take maybe ~30s at most for a reasonably sized project. I hardly used to notice the short wait.
Please provide your exact Metro configuration and mention your Metro, node, yarn/npm version and operating system.
NB Might be worth mentioning that in our setup we run in dev mode with
yarn metro
which is just a script in package.json:node node_modules/react-native/local-cli/cli.js start --reset-cache
thenyarn android
which is just a bash script along the lines of:Where adb_all is a function that loops through all connected devices / emulators and runs an adb command, in this case to reverse proxy our locally running services to the device.
The differences between our scripts and
yarn start
+react-native run-android
for the purposes of this bug report should be pretty minimal though.The text was updated successfully, but these errors were encountered: