-
Notifications
You must be signed in to change notification settings - Fork 396
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
Object size of the rfl drviers are larger than the corresponding C drivers especially when with debug symbols #1039
Comments
It does (especially if we end up with Rust used a lot, of course), but probably what matters the most are sections that take memory when loaded (e.g. |
Thanks! I will take a look at these sections. |
FWIW, 1.76.0 removes |
Thanks Weihang! I will check how much of a difference it makes for us and report it in our upgrade commit message if so. |
It reduces around a ~15% (uncompressed DWARFv4) or ~5% (compressed DWARFv4) of the original size of our |
Not much, but still an improvement :) Thanks for the update! |
Recently I have a research project about comparing the RFL drivers with C drivers. I found that Rust drivers are bigger than C especially when they are compiled with symbols. From what I observed, the Rust drivers are 2X than C drivers without debug symbols and 4-6X with debug symbols. I use the binder driver from the earlier version as an example to show this. There are two object files of the binder driver on the C side. I just use one as an example to explain.
The extra size comes from two reasons.
debug_pubnames
,debug_pubtypes
, anddebug_ranges
. There is a PR, but it is not landing due to the CI problems.debug_str
anddebug_info
. These are caused by generic programming and the wrapping functions. It is hard to optimize them for now.Before optimizing this, I want to ask for advice/opinions from the community. Does the object size of the RFL drivers matter? Is there anyone working on this?
The text was updated successfully, but these errors were encountered: