Haul: Live reload is slow and shows no indication for seconds

[pinarol]

An issue that caught our attention working with Haul was the slowness of the Live Reload. It takes several seconds to see the an indication that it is reloading(the green bar on the top) after I save the file. Total reload takes 6-8secs which is unlikely.

Could we make a root cause analysis about why this could be happening? This is not urgent to solve but we need to have a plan about how to address this one.

Haul test branch: https://github.com/wordpress-mobile/gutenberg-mobile/tree/try/haul-next-plugins

[dratwas]

Hey, @pinarol I did some investigation on this issue and I know what's going on here.
"Live reloading" works based on HTTP request which uses /onchange endpoint. RN sends a request to this endpoint in an interval, the server keeps it as a watcher and responds to it when something has changed. We do not see loader of the bundle (green bar), because haul notifies watchers when compilation is finished and it takes some time (metro is much faster in this case).
I tried to change this flow a bit to show green loader when haul starts compiling, but it generated an issue when I saved file a few times in a row. I'm going to try some changes in webpack config to make it faster.

[pinarol]

Thanks for the investigation @dratwas !

I'm going to try some changes in webpack config to make it faster.

That sounds good for the near future, for the long term I am curious if there will be some effort to make Haul compilation faster?
One thing to keep in mind might be keeping an eye on the debugging experience(source mappings/breakpoints/variable values etc)after changing webpack config and making sure it is not affected badly.

cc @koke @mkevins

[dratwas]

@pinarol I already had a little chat with @zamotany - maintainer of haul. I reported this issue to him and i hope that right now after the whole re-architecture of haul, there will be space for improvements.

[dratwas]

Hey, @pinarol I found what is the cause of long build/rebuild time with Haul. I did some profiling etc and found that we use SourceMapDevToolPlugin for source maps which is really slow. I changed it to EvalSourceMapDevToolPlugin and the time of rebuild changed from 6000ms to 400ms. Also, I checked source maps, debugger breakpoints, and values are working properly. It is still a bit slower than metro but much faster than Haul with SourceMapDevToolPlugin. Only one line has to be changed in haul.config.js to enable this option.

bundles: {
  index: {
    entry: withPolyfills( './index.js' ),
+    sourceMap: 'inline',
  }
}

I think it should be enabled only for dev builds.

BTW. We disabled HMR in Haul at this moment but I'm pretty sure we will give a try to Fast Refresh that is already on ReactNative master.
You can check issue about this here - callstack/haul#583

[koke]

I tried the inline source maps and it definitely makes live reload faster, although still not as fast as metro. From the moment the file was saved until the green bar appeared on screen I observed:

• Metro: instantly (~20ms)
• Haul with inline source maps: ~3 seconds
• Haul with regular source maps: ~10 seconds

I remember at some point in my experiments I disabled inline maps for a reason, but I haven't found anything clear in my notes. The one thing I was able to check is that if you enable inline source maps, the debugger gets a duplicate list of source files. They look identical but only one of them shows the original source:

[koke]

@mkevins do you remember any other issues with inline source maps?

[dratwas]

There will be always 2 files, one with source map, second without.
Maintainer of Haul told me that he did some tweaks within the lib and currently:

• file with source maps will exist under webpack://
• file without source maps will exist under webpack-internal://

You can check the PR here - callstack/haul#626

Another thing is that we need to realize that Haul will never be as fast as the metro.

[mkevins]

@koke 👋

do you remember any other issues with inline source maps?

Just what you described, but I chalked that up to Chrome Devtools creating the duplicate (with the ?hex parameter appended to the URL for the evaluated sourcemap version)

[koke]

we need to realize that Haul will never be as fast as the metro.

I understand this might be the reality now, but is there a fundamental reason why that’s true? Given enough time and effort spent on improving performance, wouldn’t it be possible to make haul roughly as fast as metro?

[dratwas]

I will use @zamotany explanation:

The reason haul is slower than metro is that it is based on webpack. The reason is that metro compared to webpack is smaller, targeted; whereas webpack has to support more options, which renders it complicated and way bigger in terms of just sheer lines of code. Another aspect of webpack which makes the performance worse is how the logic is written. Webpack operates on strings, slicing them, joining, mutating etc, which is one of the vectors on which the performance gets hit. You could argue that given enough time and effort you could make it more performant, but it would need ground-up rewrite of Webpack codebase, not in Haul.

[koke]

That makes sense, thanks for the explanation.