Do you get this if you run pub from the command line? Can you run with --verbose and include the results?

Added NeedsInfo label.

There's no further info. This was anonymous user feedback. Sorry, I forgot to switch the template.

Added Triaged label.

In that case, there's not really anything else we can do here.

Added CannotReproduce label.

This comment was originally written by @zoechi

This seems to be from me.
I tried to launch an Polmyer entry page from the examples directory in DartEditor.
Sometimes in the middle of serving the page the tools windows started showing 'Out of memory messages' (for example some images could not be loaded anymore). Sometimes the page load was already finished when the 'Out of memory messages started.

This comment was originally written by @zoechi

I still have this after the update to
Dart VM version: 1.5.0-edge.36950 (Tue Jun 3 14:58:04 2014) on "linux_x64"

Added this to the 1.5 milestone.
Added Triaged label.

Removed Priority-Unassigned label.
Added Priority-High label.

This comment was originally written by @zoechi

It seems that my growing entry_points list is causing the issue.
I didn't think of that because there is one complex Datagrid Polymer element in lib
and all entry pages just use this component with a slightly different configuration and some small callbacks or one or two small and simple Polymer elements.

It seems pub serve tries to build every entry page when I run one of them and my suspicion is that
every entry page is built independently without reusing the already built result of the component library from an already built entry page.

I commented out all but one entry page and the start up is way faster than recently and the page is served reliably.

Maybe the already discussed lazy transformers help here too.
I didn't yet have any problems when I built all entry pages to JavaScript to publish then to GitHub pages.
 

transformers:

• polymer:
      entry_points:

  - example/e01_simple.html

  - example/e02_formatters.html

  - example/e07_events.html

  - example/e14_highlighting.html

  - example/e03_editing.html

  - example/e03a_compound_editors.html

  - example/e03b_editing_with_undo.html

  - example/composite_editor_item_details.html

  - example/totals_via_data_provider.html

  - example/e04_model.html

  - example/e05_collapsing.html

      - example/e08_alternative_display.html

  - example/autotooltips.html

Ah, thanks for the details. This sounds like the memory usage is in the polymer transformers then.

Making them lazy would likely help here, but that hasn't happened yet. I'm bouncing this to Siggy, but I would like to still be involved here and see if there's anything we can do in pub/barback to help.

Set owner to @sigmundch.
Removed Area-Pub label.
Added Area-Pkg, Pkg-Polymer labels.

I'm marking this as blocked on getting lazy transformers in place. After that, we still need to investigate what to do after we run the transformers.

For example, we should ensure that the transformers's state & analyzer data can be collected after we run a transformer on an entrypoint.

Removed this from the 1.5 milestone.
Added this to the 1.6 milestone.
Removed Pkg-Polymer label.
Added Pkg-PolymerBuild label.
Marked this as being blocked by #19168.

Removed this from the 1.6 milestone.
Added Polymer-P-1 label.

Removed Polymer-P-1 label.
Added Polymer-Milestone-Next label.

Added PolymerMilestone-Next label.

Removed Polymer-Milestone-Next label.

Added this to the 1.6 milestone.

Removed this from the 1.6 milestone.

Fixing the blocking issue to match what Siggi said it was.

Marked this as being blocked by #16998.
Unmarked this as being blocked by #19168.

Sorry, looks like the previous issue was correct after all.

Marked this as being blocked by #19168.
Unmarked this as being blocked by #16998.

Added this to the 1.6 milestone.

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