Performance of some dart2js array store operations.

[lrhn]

See https://stackoverflow.com/questions/58211830/performance-of-dart-code-in-browser-vs-vm/

There seems to be a case here where dart2js generates a very large overhead due to slow array-store operations. Since the majority of the code is array updates, that causes an orders of magnitude slowdown over optimal code.

[rakudrama]

Parametric covariant type checks are expensive. We are currently working on making them less expensive. You could try the dart2js flag --experiment-new-rti to see how much of an improvement it provides. It is a work in progress.

To get really good code here we need to eliminate the parametric covariant type check. This is an interprocedural analysis. List<T>.generate returns an list implementation type (JSArray) with the same T, in this case T is double, so x[j]= has a check against double, which can be removed since the assigned value is double (via double+int --> double). This makes it worth inlining/reducing JSArray.$indexSet to get the JavaScript [] operation. Much of this analysis could be performed on kernel IR and shared between dart2js and AOT @alexmarkov @mraleph)

When I compile the example with -O3 or -O4 (which omits the parametric covariant type check), I get results very close to the ES6 results, both about 30ms.

[rakudrama]

The tax for doing a parametric covariant type check on array store is now much less for numeric types.

• Dart version, DartVM: 99ms
• Dart version, dart2js compiled in 'spec' mode, old type system: 4055ms
• Dart version, dart2js compiled in 'spec' mode, new type system: 154ms
• Dart version, dart2js compiled -O4: 29ms
• JavaScript version: 44ms

JavaScript times are running on a stand-alone V8. In my experience, the browser is a little slower (maybe takes and additional 50%).

I'm closing the issue since the 'orders of magnitude' problem has been fixed.