allow to share assets without serializing them within a transformer group

[sigmundch]

I'm not sure if this is worth the complexity, but here are some ideas:
 - only serialize assets if they are requested on a separate isolate
 - allow transformers to expose custom serialization/deserialization types so they can be encoded concisely in the communication with the main isolate (like FileAssets are), and decoded quickly if the asset ends up arriving back to the same isolate where they were encoded.

The main motivation I have for this is that in polymer we parse and serialize html files many times. I wouldn't be surprised if something similar is needed to process .dart files in multiple phases with the Dart analyzer. It would be great if we could parse files once, and pass the HtmlDocument to the next phase.

[sigmundch]

I tried to measure the impact of this, so I played a bit with TodoMVC, dartdoc viewer, observatory, and a small app that uses core/paper-elements.

At this time I'm not sure if it's really worth it. I found that yes, we are wasting time parsing some files multiple times, but this could also be because of how our linter is structured (we might be even parsing files multiple times within the a single transform, but with different assets as entrypoints). An extra phase that converts html strings to HtmlAssets would alleviate things, but I'm not convinced it is worth it.

In case you guys are curious, here are the numbers I found:

• todomvc:
      12 html files
      65 calls to parse HTML
      overhead: 79ms of 156ms (counting only time spent parsing HTML, if we remove the redundant parsing we would save 79ms)
• dartdoc viewer:
      28 files
      340 parse calls
      overhead: 234ms of 341ms
• observatory:
      56 files
      864 parse calls
      overhead: 1114ms of 1490ms
• paper app:
      73 files
      324 calls to parse
      overhead: 381ms of 546ms

The overhead was between 50% to 75% of the total time spent in parsing (which makes sense, we are parsing some files many times). It seems that for some small apps is not really that big of a deal, but for larger apps like observatory it starts adding up. It was especially interesting that observatory had a higher ratio of parse calls, and I think it is because of how the linter is structured. I'll look more into that.

Feel free to close this issue for now, I'm happy to report new numbers once I remove the other sources of overhead.

[DartBot]

This issue has been moved to dart-archive/barback#59.