You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 :)
The text was updated successfully, but these errors were encountered:
💡 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 :)
The text was updated successfully, but these errors were encountered: