Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

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

Closed
sethladd opened this Issue · 10 comments

4 participants

@sethladd
Owner

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?

@rakudrama
Collaborator

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)

@sethladd
Owner

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
Collaborator

Added this to the Later milestone.

@kasperl
Collaborator

Added TriageForM5 label.

@kasperl
Collaborator

Removed TriageForM5 label.

@DartBot
Collaborator

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
Collaborator

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
Collaborator

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

@kasperl
Collaborator

Removed Oldschool-Milestone-Later label.

@sethladd sethladd closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.