-
Notifications
You must be signed in to change notification settings - Fork 116
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
Investigate compile sizes #185
Comments
Just tried for the
Maybe the last line is relevant here?
I don't really see how
|
Interestingly, it doesn't show up when building WR examples, only when building Wrench. The difference is that Wrench enables the serde deserialization attributes on a whole ton of structs, plus the code to actually use them (that calls into Ron). |
The size blamed on ron is stuff like:
This is just the actual specialized serialize/deserialize methods. Also cargo bloat reports compiled size and not compile times. |
If you compile with the new mangling scheme you can even get more info about what's going on:
|
The idea we discussed with @jrmuizel would be to move as much deserialization code as possible from being monomorphised into run-time. For example, we may have a small piece of code parsing RON and generating run-time reflection of a struct (non-generically), so that RON deserialization then works off it. |
Yeah, so you could have #[derive(Reflect)] which would try to produce a compact representation of the struct and add a method that returns a reference to this compact representation which implements Deserialize. |
Just tried to run cargo-bloat on Wrench (the binary we use for WebRender debugging) and saw this:
The text was updated successfully, but these errors were encountered: