Skip to content
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

Sort by crate #705

Open
mcclure opened this issue May 18, 2023 · 1 comment
Open

Sort by crate #705

mcclure opened this issue May 18, 2023 · 1 comment
Labels
enhancement New feature or request good first issue Good for newcomers

Comments

@mcclure
Copy link

mcclure commented May 18, 2023

💡 Feature Description

Offer a mode/flag where instead of listing individual functions, functions which stem from the same crate are lumped together to show single aggregate numbers per crate.

Several of Twiggy's modes could benefit from crate awareness. "Top" showing top crate contributors is an obvious use. In dominators mode Twiggy could use cargo tree -i or similar information to indicate a crate's total footprint by combining its footprint along with the crates it includes directly or indirectly.

There are various ways this could be made fancier (offer a flag for sorting generic functions with the crate that provided them, VS the crate that forced their specialization; optionally do or don't lump in an included crate's footprint with the including crate's footprint, depending on whether the including crate is unique in including the included crate; have some way to rather than collapsing functions into crates completely, collate and sort functions within crates, which might give hints as to which "feature"s within the crate are causing additional space footprint) but even a basic implementation would be very helpful.

💻 Example Usage

I can give you a real example. In this project (commit c6dcc33 can be run in a browser here) I have a fairly small Rust project to which most of the space contribution comes from included crates (I know this because in a short series of commits I added 4 or 5 new high-level crates and my space usage increased from ~100k to ~1MB). My problem then becomes not what code of mine is causing the size explosion? but rather which crates should I try to figure out a way to live without?. Twiggy's function-oriented space display means it can answer this question only indirectly.

For a more specific example, I started off fairly certain that my PNG loader (the "image" crate) was causing a large contribution. In my first pass with Twiggy, I was able to find that I had misconfigured the PNG loader to also include a JPEG and TIFF loader; turning those features off decreased footprint 50%, but even after this the PNG functions are still a major contribution.

So that's a good start and Twiggy has already been useful. However, the remaining PNG contribution to the impact consists of a large number of individually-smaller functions rather than one or two big functions. It is hard for me to tell if I should focus primarily on the PNG loader or try other things first. For example, at the moment my random crate has the biggest single function, but underneath this in the list are many PNG functions. Do the PNG functions add up to more than the random crate's one big function? I'd have to do lots of math in my head to tell.

Similarly, imagine I were to find a different PNG crate, and do an experiment where I replaced "image" with my alternate PNG loader to see how the size footprint changes. Twiggy has a "diff" feature, but that diff feature can't specifically tell me "in THIS build the image crate took up N kb, but in THIS build the zune-png crate took up M kb". I could compare the topline executable size from each build, but for that I wouldn't specifically need Twiggy.

A final observation from this example, in my Twiggy tests I find a function from the Hashbrown crate is currently creating quite a large footprint. I'm not using hashbrown. I can use cargo tree -i to see which crates use hashbrown, but currently it appears all hashbrown users are not relevant to the wasm build (either desktop-specific crates or build-specific crates). I can probably do the detective work to figure this out, but because Twiggy has the full call graphs of a complete (and, I hope, tree-shaken?) wasm binary at its disposal, it could figure this out and come to the conclusion of "hashbrown is taking up N kb because the web-sys-wgpu crate is including it" (or whatever) more easily than I could,

🙌 Are you interested in implementing this feature?

At a different time I might answer "Yes if I had a mentor to help me" but given my current time commitments the answer is "No". Sorry :)

@AlexEne
Copy link
Collaborator

AlexEne commented May 18, 2023

I like this request, thanks for suggesting it!

@AlexEne AlexEne added good first issue Good for newcomers enhancement New feature or request labels May 18, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request good first issue Good for newcomers
Projects
None yet
Development

No branches or pull requests

2 participants