-
-
Notifications
You must be signed in to change notification settings - Fork 774
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
Migration to serde from rustc-serialize causes binary to grow significantly #286
Comments
Are you compiling with optimizations? Have you tried enabling link time optimizations? |
I run with |
Well... Rust's monomorphisation doesn't merge identical implementations yet. We could improve on this probably by adjusting the macros that generate all the code |
|
From IRC on how eddyb creates a count of monomorphized functions in order to debug compiler memory usage (and also executable size):
I will try this and see if there is any low-hanging fruit. |
Command to show which symbols contribute the most to binary size: nm -S target/debug/json-benchmark \
| awk '{
print $4 |& "rustfilt";
"rustfilt" |& getline id;
sub(/::h[0-9a-f]{16}$/, "", id);
sums[id] += strtonum("0x"$2);
counts[id] += 1
}
END{
for (id in sums) {
printf "%8s %4s %s\n", sums[id], counts[id], id
}
}' \
| sort -nr \
| head -16 The first column is total number of bytes associated with that function across all the different instantiations of it, second column is number of different instantiations of the function (with different generic types etc). I ran it on json-benchmark for lack of a better thing to run it on. Debug mode:
Release mode:
The number parsing is definitely something we can improve. Those functions are generic on the Visitor type but they do a lot of work that does not touch the visitor and could be factored out. I don't see any other obvious culprits. We just need to work through these and reduce the number of redundant copies of code being compiled. |
If anyone has large binary projects using Serde where you care about compile time / executable size, please comment with a link to the repo. I would like to make sure that the things we optimize will actually improve your situation. |
serde-rs/json#313 has a good minimal case to reproduce this. extern crate pandoc_ast;
fn main() {
pandoc_ast::filter(String::new(), |p| p);
} Instantiations are listed in serde-rs/json#313 (comment). Again I think we should tackle the number parsing area first. |
…viper impl remaining num-traits for std::num::Wrapping<T> This is a (late) follow-up for [https://github.com/rust-num/num/pull/279](https://github.com/rust-num/num/pull/279) since I realized that implementing `Num` for `Wrapping<T>` was merely half of the work. This PR makes `Wrapping<T>` implement the remaining appropriate traits, granting it the ability to really be used a complete substitute for its primitive integer counterparts. Some benefits are : - Less refactoring for users using `num`'s traits replacing some primitives by their `Wrapping` counterpart (same for the opposite); - Since `Wrapping<T>` is from `std`, nobody except us can `impl` our traits for it, so people don't have to create their own.
I'm seeing a pretty big impact on xi-editor. Debug:
Release:
That's measured on linux. Happy to do more digging, and try low-hanging fruit that might improve things. |
Thanks Raph! Those ContentDeserializer::deserialize_any, ContentRefDeserializer::deserialize_any, and Value::deserialize_any numbers definitely should not be that high. I will see what I can do. So far there has not been any effort to optimize any of those. ContentRefDeserializer shows up when dealing with untagged enums and ContentDeserializer shows up in internally tagged and adjacently tagged enums. They are the mechanism Serde uses for buffering data until we are able to determine which variant of the enum we are looking at. |
@dtolnay We're heavily using the Thanks for any help in improving this. |
As a start, I opened xi-editor/xi-editor#617 with a 22% improvement from upgrading to serde 1.0.39 and serde_json 1.0.15. |
I opened xi-editor/xi-editor#628 with a 12% improvement this time focusing on the release binary. |
Some time ago I migrated my crate to serde from rustc-serialize and I was somewhat dissapointed that my binary size increased approximately 2x (and so did compilation times).
If I run
nm --size-sort -S
, I get a lot of symbols like this:With
rustc-serialize
, seems like there is no such symbol mutiplication.OS X
rustc 1.9.0-nightly (a43eb4e77 2016-04-12)
,serde 0.7.0
(I also tried on Windows and results are the same)The text was updated successfully, but these errors were encountered: