Much slower react-scripts-ts build in node-chakracore v10.0.0
#527
Comments
kfarnung
changed the title
react-scripts-ts build in node-chakracore v10.0.0react-scripts-ts build in node-chakracore v10.0.0
|
I had a look at this on macOS (obtained puzzle-web from your GitHub repository to test) and didn't notice nearly as big a speed drop only about a 10% regression. Could there be something windows specific here? Though whilst the regression was not as significant in both cases v8 node took less than half the time. That said I'd thought I'd try and determine the source of the 10% regression. Profiling showed that (on macOS at least) most of the time is spent within ChakraCore inside JavascriptArray::EveryHelper - the implementation of Array.prototype.every. The 10% regression seemed to relate to this change: chakra-core/ChakraCore#4511 Reverting it gave a 5-10% improvement. I tried implementing Array.prototype.every in javascript inside chakra_shim.js and this gave around a 10-20% improvement. I then tried updating to latest master of chakracore - latest master combined with the JS implementation of Array.prototype.every resulted in a comparable speed to v8 node, still slower but 10-20% slower instead of double the length. Note latest master without the JS implementation of array.prototype.every was not nearly as significant an improvement - I assume the large speedup I observed was due to the combination of the JS implementation of Array.prototype.every and this recent CC change: chakra-core/ChakraCore#5081 |
|
That's some interesting data, I hadn't actually measured the time on macOS, the numbers I've collected have been from Linux and Windows. I actually see the biggest speed drop on Linux, the numbers in the original post were from a VM running Ubuntu 16.04 and the original source of this issue was actually some Travis-CI runs where the speed is consistently much slower: https://travis-ci.org/kfarnung/puzztool/builds/374762013 Digging down into the individual legs it took On Windows the drop isn't quite as pronounced (but the tests were all run on different hardware too, so that's likely a factor): > Measure-Command { npm run build }
Warning: Ignored engine flag: --max-old-space-size=2048
Days : 0
Hours : 0
Minutes : 1
Seconds : 5
Milliseconds : 646
Ticks : 656466906
TotalDays : 0.000759799659722222
TotalHours : 0.0182351918333333
TotalMinutes : 1.09411151
TotalSeconds : 65.6466906
TotalMilliseconds : 65646.6906> Measure-Command { npm run build }
Warning: Ignored engine flag: --max-old-space-size=2048
Days : 0
Hours : 0
Minutes : 1
Seconds : 38
Milliseconds : 506
Ticks : 985061608
TotalDays : 0.00114011760185185
TotalHours : 0.0273628224444444
TotalMinutes : 1.64176934666667
TotalSeconds : 98.5061608
TotalMilliseconds : 98506.1608 |
|
I don't have a linux machine to test on - considering that chakra's macOS and linux builds are very similar I'm very surprised about the difference though - only a 10% regression on my MacBook vs that 300% regression. Not sure if I can do much more as it sounds like this needs profiling on linux specifically. |
|
Well, that is interesting indeed. I added macOS to the CI script and the results are much more inline with what you're seeing: https://travis-ci.org/kfarnung/puzztool/builds/375131975 92.89 vs 132.03 seconds EDIT: Looks like the v8.11.1 leg failed with a native module incompatibility: EDIT2: But it looks like the build did pass, so it's probably a valid test. |
|
Taking a perf trace on Linux node-chakracore v8.11.1 node-chakracore v10.0.0 |
|
Perhaps node v10 is throwing more exceptions? You could try counting that using |
|
I tried profiling again with current node-chakracore, with CC master and with array.prototype.every overwritten with a JS implementation. (Note total execution time at this point was significantly shorter than node-chakracore v8.11.1's time as in 60% as long or something like it - I assume a JS implementation of array.prototype.every is incoming for ChakraCore in light of the inlining work that's been done and the current PR for array.prototype.indexOf - so this benefit should be seen in a future release) That aside with these steps, the profile trace was now dominated by Javascript Try operators, and a couple of ThrowException operators as well as a few bail out related calls. |
|
After looking at the point identified above about array.prototype.every which is used so heavily in react-scripts-ts build I reviewed the benchmarks included in the chakracore repository and cannot find one that exercises array.prototype.every - should there be/is there an action around assessing the completeness of those benchmarks? Unless already being worked on I could make a PR to add a JS implementation of array.prototype.every to CC but it won't effect cc's own benchmarks at all - it will affect this massively though. |
|
Sorry for the delay, I don't believe anyone is currently working on Ping @sigatrev to confirm. |
|
@rhuanjl I confirmed that there's nobody working on |
|
Thanks - I'll have a look at it shortly, not sure I want to open any more CC PRs until a couple of my existing ones are done though. |
|
Something else seems to have changed since I did the profiling above. I made a JS implementation of array.prototype.every for CC but using it with latest CC master it's not showing the performance improvement I had before at all. Additionally simply putting in a JS implementation into chakra_shim.js as I did before isn't showing the same speedup anymore either; I'll hold off on submitting anything and do some more profiling + see if I can work out what's changed. |
|
Been looking at this more - using my implementation of Array.prototype.every (in this branch: https://github.com/rhuanjl/ChakraCore/tree/every ) performance now seems similar or slightly worse than with current CC master/CC 1.10.1. When using that much of the time in the trace is in JavascriptFunction::GetCallerProperty - I'll look into why that could be slow. It seems to be taking forever a) throwing type errors AND b) finding the caller of the function that threw them Having a JS implemented every method seems to make this finding of the caller slower. (I assume these type errors are all inside try/catch blocks as the build completes successfully) Could anything have made the handling of finding the caller when an error is thrown slower? |
Comparing the build times for
react-scripts-ts buildbetween node-chakracore v8.11.1 and v10.0.0 there's a huge difference in runtime.node-chakracore v8.11.1
node-chakracore v10.0.0
The text was updated successfully, but these errors were encountered: