-
Notifications
You must be signed in to change notification settings - Fork 5
Add support for analyzing GopherJS artifact size. #3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
a169a54 to
a1f5e57
Compare
|
fix and update workflows action and please merge master |
When --analyze_size flag is passed to GopherJS, an additional
${packagename}.js.svg file is creates with a TreeMap diagram that
visualizes which packages contributed to the artifact size and how much.
The data is obtained by counting bytes written for each section of the
file including GopherJS's own prelude and works accurately both in
minified and default modes.
Most of diagram-related logic is isolated to the build/analysis package
with minimal changes to the rest of the code base.
a1f5e57 to
0c991f0
Compare
|
Synced with the master branch, but I'm not sure what workflow action fix you mean. |
|
@visualfc could you please clarify what else needs to be fixed in this PR or whether you are interested in merging it? |
It's cool, but users may just need a simple text display. generate svg format is a other tools and can parser this text format. |
|
First of all, apologies for taking so long to respond, december was a busy month. Adding text output option makes sense. I've experimented with it a bit before going on to implement SVG rendering and found that for any real-life project it is very difficult to understand, even when printed in a tree-like form. That said, I could still see how it could be useful to track artifact size changes in a CI system or something like that. Example output: Moving SVG rendering into a separate tool is not very practical because it would need the dependency tree and a lot of meta information that are only available to the gopherjs compiler (in particular differences due to build tags and stdlib augmentation). It will require a much more complicated format to pass that on, which won't be human-readable. As a middle ground I could offer to move most of the size analysis and/or SVG rendering logic into a separate package which I'd maintain myself, and import that from GopherJS codebase. |
23ada84 to
5f6ecdf
Compare
|
@nevkontakte |
When --analyze_size flag is passed to GopherJS, an additional
${packagename}.js.svg file is creates with a TreeMap diagram that
visualizes which packages contributed to the artifact size and how much.
The data is obtained by counting bytes written for each section of the
file including GopherJS's own prelude and works accurately both in
minified and default modes.
Most of diagram-related logic is isolated to the build/analysis package
with minimal changes to the rest of the code base.