polymer: '>= 0.10.0-pre.13'

Chrome is completely blocked during the 50 seconds and the CPU is pegged.

cc @sigmundch.
cc @jmesserly.

Removed Area-Polymer label.
Added Pkg-Polymer, Area-Pkg labels.

The behaviour is different in Dartium vs. dart2js in Chrome.

In Chrome while the polymer expressions are being run the browser exits to the main loop repeatedly (allowing scrolling/painting). It looks like the expressions are put in a queue and are processed individually (!).

In Dartium the whole page freezes until everything is rendered (still a very long time).

cc @justinfagnani.

I'm writing a benchmark for this.

I'm having a hard time reproducing the extreme slowdowns. I'm creating 2000 custom elements in a <template repeat>, bound to an observable model, in about 1.5s in Dartium and 2s in Chrome/dart2js.

We need to look at more specifics of the Observatory case to see what triggers this.

Note that this will busy loop the isolate, but you can still connect to it using the observatory.

class Foo {
  factory Foo.boom(val) {
    if (val != 0) {
      return new Foo.boom(--val);
    }
    var x = 0;
    while (true) {
      x++;
    }
    return 1;
  }
}

main() {
  try {
    new Foo.boom(2000);
  } catch(e, s) {
    print(e);
    print(s);
  }
}

Run it as below, connect with the observatory and take a look at the stacktrace.
dart --observe --trace-service ~/dart/Bug19064.dart

I see that the Observatory client makes heavy use of ObservableMaps and does a lot of copying of key/value pairs into the maps. I thought this could be a source of the problem, but I still haven't been able to create an isolated reproduction.

Observatory's template repeat instantiates multiple custom elements some of which have template if's.

This is trivial to reproduce with Observatory in both Dartium and Chrome (Dart2JS) with Ivan's script.

Polymer elements in a repeat can be slow (that was my first guess). But the example snippet above looks like just a plain repeat of a table.

Hi,

Sorry the example in my original post was overly simplified (and from a different page than stacktrace). The source for Observatory ships with the VM so it's trivial to reproduce on your machine using Ivan's example. I'm happy to walk you and Justin through this part of our code.

John

Sure, it's just very hard to isolate performance in the context of a full app. I think that's why Justin spent a long time yesterday trying to isolate it to a smaller reproduction. In general with bugs, smaller repros are goodness :)

Anyway it sounded like Justin's digging into this so assigning to him.

Set owner to @justinfagnani.

I've tried to reproduce by using more and more pattern from Observatory with no luck so far. Currently I'm populating an ObservableList of ObservableMaps, using map.clear() and map.allAdd() like Observatory does, and binding to a custom element that has a <template if> inside.

For 2000 items, the mutation takes about 2 seconds, and then there's about another half second of style calc. I think this is about inline with what we expect. For 200 items, it's .4s and for 10000 items it's ~8.5s. So far it looks sublinear, not like what we suspect is n^2 like we're seeing in Observatory.

I've attached my reproduction attempt. I'm thinking more and more that this slowdown might have to do with deserialization and the use of ObservableMaps as model objects. I think at this point we either need to successfully repro the issue in an isolated case, or instrument Observatory to see where the time is actually being spent.

Attachment:
repeat.tgz (2.21 KB)

Added this to the 1.5 milestone.

I tried to run look at the Observatory in Dartium (Observatory on Observatory, awesome!), and found the following:

68% in GCNewSpace
30% in Script:
 23.66% _localInstanceMirror.getField
 16.80% HtmlElement&Polymer&Observable.deliverChanges
 13.33% HtmlElement&Polymer&Observable.hasObservers
 10.88% Subtype1TestCache
 ...

We did the same yesterday (Observatory on Observatory- Obseception?) and noticed that the exceptions being thrown from polymer_expressions were very high on the profile. That's been fixed and now we are spending most of the time inside an embedder provided native function. I'm narrowing which one that is down now.

Sorry, I should have mentioned that I landed

https://codereview.chromium.org/314583004/
and
https://codereview.chromium.org/310903003/

To address the exceptions (which were expression warnings).

The fixes in comment 18 were tracked by issue #18347.

This issue has been moved to dart-archive/polymer-dart#196.