Open Richardhongyu opened 8 months ago
Does the object size of the RFL drivers matter?
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. .text
, .data
, .rodata
, .bss
and so on marked with SHF_ALLOC
).
Thanks! I will take a look at these sections.
FWIW, 1.76.0 removes .debug_pubnames
and .debug_pubtypes
via https://github.com/rust-lang/rust/pull/117962.
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 kernel.o
. :)
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?