dart-archive / barback

An asset build system for Dart.
https://pub.dartlang.org/packages/barback
BSD 3-Clause "New" or "Revised" License
10 stars 9 forks source link

allow to share assets without serializing them within a transformer group #59

Open DartBot opened 9 years ago

DartBot commented 9 years ago

Issue by sigmundch Originally opened as dart-lang/sdk#20858


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.

DartBot commented 9 years ago

Comment by 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:

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.