Accessor newtypes #465
Accessor newtypes #465
Conversation
rust-highfive
added
S-waiting-on-review
Oh my this really blows up the size of the release build! I thought that the newtype pattern was basically optimized away by the compiler, but it seems that either something is preventing that from happening or the compiler's handling of it is not as good as I thought it was. |
|
Upon closer inspection, most of that extra junk is in
My intuition is that As a general matter, what's the best way to do this sort of profiling? |
| impl core::ops::Deref for R { | ||
| type Target = crate::R<#name_uc_spec>; | ||
|
|
||
| fn deref(&self) -> &Self::Target { |
There was a problem hiding this comment.
Add #[inline(always)] for each Deref and DerefMut first and retest.
Do you use cargo size from cargo-binutils or something else?
There was a problem hiding this comment.
That did it! Now it's exactly the same size.
These numbers are from my system avr-size. I just tried with cargo-binutils and I'm getting 'Failed to parse crate metadata'.
couchand
force-pushed
the
202008/accessor-newtype
branch
from
a984c74 to
a4bfbae
Compare
|
Rebased on top of master, please take another look. Re: #466 (comment) For For There's some increase in the generated code size, but not a lot. |
466: Avoid register type aliases r=therealprof a=couchand Part 3 of #463, builds on #465. - Removes generated use of the register type aliases in favor of directly referencing `Reg<REGISTER_SPEC>`. I think this helps clarify how the generated and generic types work together. No breaking change concerns on this change set. r? @burrbull Co-authored-by: Andrew Dona-Couch <[email protected]>
|
Size increase looks reasonable. There's still a lot of (medium high hanging) fruit to pick. I'll soft approve and let give @burrbull have a second look. |
Part 2 of #463, builds on #464.
Again there's some minor potential for breaking changes:
r? @burrbull