Something is strange for angular and partial update

[krausest]

I tried to create a new angular version with angular cli (currently labeled angular-ng) since the closure build doesn't work on windows. It'a pretty much as fast as the committed angular version with the exception of partial update.
This was strange since the application code and template was basically the same, except the committed angular version still included the much discussed and little beloved startMeasure / stopMeasure calls.
Adding and removing those in the respective version lead to the following result:

The upper measurement is with startMeasure and stopMeasure calls and the lower without.
Sounds very odd.

I then removed all of those measurements to see if other frameworks have the same issue:

Seems like only angular and angular-ng are affected (and you can notice that for angular the difference is much smaller than in the example above).

[krausest]

I can't replicate the issue without CPU throttling. Here are a few results:

With startMeasure/stopMeasure:
result angular-v8.2.14-keyed_03_update10th1k_x16.json min 11.961 max 29.896 mean 19.7673 median 16.444 stddev 7.101551818675502
result angular-v8.2.14-keyed_03_update10th1k_x16.json min 11.451 max 30.805 mean 18.5595 median 16.041 stddev 6.323426448971756
result angular-v8.2.14-keyed_03_update10th1k_x16.json min 11.615 max 30.233 mean 19.682499999999997 median 16.737499999999997 stddev 7.585571585436248
result angular-v8.2.14-keyed_03_update10th1k_x16.json min 13.287 max 28.29 mean 18.95 median 15.8935 stddev 5.957594294493187

Without startMeasure/stopMeasure:
result angular-v8.2.14-keyed_03_update10th1k_x16.json min 13.806 max 24.97 mean 17.443999999999996 median 15.792000000000002 stddev 3.7587347161866407
result angular-v8.2.14-keyed_03_update10th1k_x16.json min 12.684 max 29.527 mean 20.431500000000003 median 17.805 stddev 6.462883072678254
result angular-v8.2.14-keyed_03_update10th1k_x16.json min 12.046 max 28.976 mean 19.690099999999997 median 18.4285 stddev 5.158979043053641
result angular-v8.2.14-keyed_03_update10th1k_x16.json min 10.547 max 28.929 mean 17.971200000000003 median 17.231 stddev 5.356158009452505

[krausest]

Nevertheless I decided to remove all startMeasure/stopMeasure calls. There are gone now for all keyed implementations.

[krausest]

It's really confusing. Adding startMeasure/stopMeasure makes angular-ng as fast as angular.
The other finding is that using the closure compiler instead of rollup seems to help too:
With closure:
result angular-v8.2.14-keyed_03_update10th1k_x16.json min 141.773 max 178.089 mean 157.60219999999998 median 157.5935 stddev 10.67830661564734
Just rollup:
result angular-v8.2.14-keyed_03_update10th1k_x16.json min 161.568 max 181.876 mean 170.5089 median 169.6295 stddev 7.42753732852731

[leeoniya]

The other finding is that using the closure compiler instead of rollup seems to help too

whether Closure Compiler helps or hurts perf is really dependent on the code being compiled. really any minifier that non-deterministically inlines functions for byte size reduction suffers from this in the absence of explicit annotations. a single character change may exclude a function from being inlined, or force it to be inlined, which can easily have a large effect on how JITs behave at runtime.

google/closure-compiler#2751
https://github.com/terser/terser#annotations

for instance, in domvm Closure was always inlining syncChildren [1] since there was only a single callsite for it. this bloated the containing function enough where the JIT bailed on it and perf dropped significantly.

since then i use terser and disable inlining globally. in the long term it has been beneficial. the perf benefits of keeping functions isolated and JIT-able outweighs the meager byte savings attained by inlining.

[1] https://github.com/domvm/domvm/blob/master/src/view/syncChildren.js#L103

[krausest]

I'm closing this issue since I currently can't build angular 11 with closure.