Tool to determine line of code impact on generated JS size #9876

sethladd opened this Issue Apr 13, 2013 · 10 comments


None yet

5 participants


A customer has asked for a way to determine the impact a line of Dart code has on generated JS file size. Their goal is to produce small and fast JS, and understanding cause and effect is important to them.

I think we started to use Source Maps when looking at dart:html output size, yes?


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.

kasperl commented Apr 22, 2013

Added this to the Later milestone.

kasperl commented May 23, 2013

Added TriageForM5 label.

kasperl commented May 28, 2013

Removed TriageForM5 label.

DartBot commented Jun 26, 2013

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 :)

DartBot commented Jun 26, 2013

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.

kasperl commented Jul 10, 2014

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

kasperl commented Aug 4, 2014

Removed Oldschool-Milestone-Later label.

@sethladd sethladd closed this Jun 4, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment