I used Source Maps for some rough estimates, but at present, they are not all that reliable for this purpose.

To give an accurate picture, we would want to attribute each byte of JS with some source code. In general this is not possible, but even where it is, Source Maps are not the right tool since they map executable statements for single-stepping in the debugger. Only ~10% of the JS is referenced in Source Maps, but that is fine if that covers the start of each single-step reachable statement.

We could try to abuse Source Maps by adding mappings between 'non-executable' fragments of JS and Dart to get a better picture of "Where's the beef?". I don't know if doing this will make the Source Maps less suitable for debugging.

I'm not sure what to do about the little changes that have global impacts:
 - Renaming a method from 'add' to 'retain' might cause many call sites to the other 'add' methods to improve in code quality.
 - Adding noSuchMethod might add a lot of small helper functions but it is impossible to attribute them to a specific noSuchMethod definition.
 - One call site to a function might be the reason that dart2js thinks the function needs bailouts, but by the time dart2js is figuring out to use bailouts, there is no trace of the causal relationship, just that the types passed in might benefit from bailouts.

Does the customer want this of plain code or minified code? (I think in most cases they would be proportional)

Thanks Stephen. The customer is looking for insight into where the generated JS code is coming from. Adding a single line of Dart might pull in many, many lines of JS, so they are curious how to track it down.

Added this to the Later milestone.

Added TriageForM5 label.

Removed TriageForM5 label.

This comment was originally written by @sethladd

This would be pretty useful for our app, which is clocking in at 4.2MB of JavaScript, which takes 20 seconds to load/parse the script on mobile. It would be awesome to figure out how we got to 4.2MB of JS. Our app is definitely not 4.2MB of dart source code :)

This comment was originally written by @sethladd

How about this initial idea:

Print out how much noSuchMethod is costing you, and where you use it.
Print out how much mirrors is costing you, and where you use it.

If those are the biggest culprits (is this still the case?) then perhaps helping the developer find where and how often they are used is a good first step.

Removed this from the Later milestone.
Added Oldschool-Milestone-Later label.

Removed Oldschool-Milestone-Later label.

Check out https://github.com/dart-lang/dump-info-visualizer