Skip to content

Conversation

gmarcosb
Copy link
Contributor

Fixes #314

@gmarcosb gmarcosb requested a review from ivmarkov October 15, 2025 20:44
Copy link

PR #329: Size comparison from b4bfd38 to 651abce

Increases above 0.2%:

platform target config section b4bfd38 651abce change % change
linux dimmable_light rs-matter FLASH 2236232 2241040 4808 0.2
Full report (3 builds for linux)
platform target config section b4bfd38 651abce change % change
linux dimmable_light rs-matter FLASH 2236232 2241040 4808 0.2
RAM 42776 42776 0 0.0
onoff-light rs-matter FLASH 2137800 2136704 -1096 -0.1
RAM 42760 42760 0 0.0
speaker rs-matter FLASH 2209256 2208208 -1048 -0.0
RAM 5528 5528 0 0.0

Copy link
Contributor

@ivmarkov ivmarkov left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As per the comments.

@ivmarkov
Copy link
Contributor

PR #329: Size comparison from b4bfd38 to 651abce

Increases above 0.2%:

platform target config section b4bfd38 651abce change % change
linux dimmable_light rs-matter FLASH 2236232 2241040 4808 0.2
Full report (3 builds for linux)

@gmarcosb Looks quite nice!

But I would not trust it until we have the dedicated guinea-pig executable. Which is compiled with - say - opt-level="z" or opt-level="s".

Standard Rust debug builds are opt-level=0 which is non-telling.

@gmarcosb
Copy link
Contributor Author

PR #329: Size comparison from b4bfd38 to 651abce
Increases above 0.2%:
platform target config section b4bfd38 651abce change % change
linux dimmable_light rs-matter FLASH 2236232 2241040 4808 0.2
Full report (3 builds for linux)

@gmarcosb Looks quite nice!

But I would not trust it until we have the dedicated guinea-pig executable. Which is compiled with - say - opt-level="z" or opt-level="s".

Standard Rust debug builds are opt-level=0 which is non-telling.

Sweet, it worked! Hot damn on the first try, not bad!

So this is what I'm using for the builds, is it not enough?

cargo build --release --no-default-features --features os,rustcrypto,log

(this is in https://github.com/gmarcosb/rs-matter/blob/main/.github/workflows/size-check.yml)

@ivmarkov
Copy link
Contributor

ivmarkov commented Oct 15, 2025

PR #329: Size comparison from b4bfd38 to 651abce
Increases above 0.2%:
platform target config section b4bfd38 651abce change % change
linux dimmable_light rs-matter FLASH 2236232 2241040 4808 0.2
Full report (3 builds for linux)

@gmarcosb Looks quite nice!
But I would not trust it until we have the dedicated guinea-pig executable. Which is compiled with - say - opt-level="z" or opt-level="s".
Standard Rust debug builds are opt-level=0 which is non-telling.

Sweet, it worked! Hot damn on the first try, not bad!

So this is what I'm using for the builds, is it not enough?

cargo build --release --no-default-features --features os,rustcrypto,log

(this is in https://github.com/gmarcosb/rs-matter/blob/main/.github/workflows/size-check.yml)

--release (by default) is opt-level=3, which means "optimize for speed, code-size go to hell" i.e. it does very aggressive inlining. On baremetal where code-size matters folks:

  • Use opt-level="z" or "s"
  • Use defmt (not log)
  • Sometimes take drastic measures like -Zbuild-std-features=panic_immediate_abort which cuts down .rodata even more (but you lose the panic messages).

We'll discuss those in more detail once we have the guinea pig executable. It should btw NOT target linux either, but a baremetal core-only target.

EDIT: And use other tricks like codegen-units=1 and then the new "fat" LTO which can eliminate more dead code.
This is a typical setup for a baremetal build which targets devices with a tiny flash.

Copy link

PR #329: Size comparison from b4bfd38 to 4e45cc3

Increases above 0.2%:

platform target config section b4bfd38 4e45cc3 change % change
linux dimmable_light rs-matter FLASH 2236232 2241040 4808 0.2
Full report (3 builds for linux)
platform target config section b4bfd38 4e45cc3 change % change
linux dimmable_light rs-matter FLASH 2236232 2241040 4808 0.2
RAM 42776 42776 0 0.0
onoff-light rs-matter FLASH 2137800 2136704 -1096 -0.1
RAM 42760 42760 0 0.0
speaker rs-matter FLASH 2209256 2208208 -1048 -0.0
RAM 5528 5528 0 0.0

@gmarcosb
Copy link
Contributor Author

PR #329: Size comparison from b4bfd38 to 651abce
Increases above 0.2%:
platform target config section b4bfd38 651abce change % change
linux dimmable_light rs-matter FLASH 2236232 2241040 4808 0.2
Full report (3 builds for linux)

@gmarcosb Looks quite nice!
But I would not trust it until we have the dedicated guinea-pig executable. Which is compiled with - say - opt-level="z" or opt-level="s".
Standard Rust debug builds are opt-level=0 which is non-telling.

Sweet, it worked! Hot damn on the first try, not bad!
So this is what I'm using for the builds, is it not enough?

cargo build --release --no-default-features --features os,rustcrypto,log

(this is in https://github.com/gmarcosb/rs-matter/blob/main/.github/workflows/size-check.yml)

--release (by default) is opt-level=3, which means "optimize for speed, code-size go to hell" i.e. it does very aggressive inlining. On baremetal where code-size matters folks:

  • Use opt-level="z" or "s"
  • Use defmt (not log)
  • Sometimes take drastic measures like -Zbuild-std-features=panic_immediate_abort which cuts down .rodata even more (but you lose the panic messages).

We'll discuss those in more detail once we have the guinea pig executable. It should btw NOT target linux either, but a baremetal core-only target.

EDIT: And use other tricks like codegen-units=1 and then the new "fat" LTO which can eliminate more dead code. This is a typical setup for a baremetal build which targets devices with a tiny flash.

Sounds like a plan 👍 Should just be a matter of updating the CLI in size-check.yml to whatever optimization we want

@ivmarkov
Copy link
Contributor

Heh. The "RAM" of the speaker example is only 5K. That's because it is written in a way where everything is placed on-stack. One more reason to have the guinea-pig ELF, where we can place as much as possible stuff in .bss so that we get a more realistic memory estimation.

@gmarcosb gmarcosb mentioned this pull request Oct 15, 2025
Copy link

PR #329: Size comparison from b4bfd38 to 7dc00f9

Increases above 0.2%:

platform target config section b4bfd38 7dc00f9 change % change
linux dimmable_light rs-matter FLASH 2236232 2241040 4808 0.2
Full report (3 builds for linux)
platform target config section b4bfd38 7dc00f9 change % change
linux dimmable_light rs-matter FLASH 2236232 2241040 4808 0.2
RAM 42776 42776 0 0.0
onoff-light rs-matter FLASH 2137800 2136704 -1096 -0.1
RAM 42760 42760 0 0.0
speaker rs-matter FLASH 2209256 2208208 -1048 -0.0
RAM 5528 5528 0 0.0

Copy link

PR #329: Size comparison from b4bfd38 to ed742a8

Increases above 0.2%:

platform target config section b4bfd38 ed742a8 change % change
linux dimmable_light rs-matter FLASH 2236232 2241040 4808 0.2
Full report (3 builds for linux)
platform target config section b4bfd38 ed742a8 change % change
linux dimmable_light rs-matter FLASH 2236232 2241040 4808 0.2
RAM 42776 42776 0 0.0
onoff-light rs-matter FLASH 2137800 2136704 -1096 -0.1
RAM 42760 42760 0 0.0
speaker rs-matter FLASH 2209256 2208208 -1048 -0.0
RAM 5528 5528 0 0.0

@gmarcosb
Copy link
Contributor Author

Will be doing a bit of #258 to eliminate atomic

@ivmarkov
Copy link
Contributor

ivmarkov commented Oct 15, 2025

Will be doing a bit of #258 to eliminate atomic

I suggest you reconsider.
#258 has enormous scope. You might end up in a never-ending PR if you start to tackle #258 just because of #329. For now, just putting two extra mutexes (or one mutex and one cell) is good enough to have #329 solved.

#258 is a whole other story. If you want to address it - be my guest, but doing it "just because" of #329 is not worth it.
#258 will require changes throughout the whole rs-matter codebase. All system clusters, Matter, transport, IM, DM, everything everything.

@gmarcosb
Copy link
Contributor Author

gmarcosb commented Oct 16, 2025

Will be doing a bit of #258 to eliminate atomic

I suggest you reconsider. #258 has enormous scope. You might end up in a never-ending PR if you start to tackle #258 just because of #329. For now, just putting two extra mutexes (or one mutex and one cell) is good enough to have #329 solved.

#258 is a whole other story. If you want to address it - be my guest, but doing it "just because" of #329 is not worth it. #258 will require changes throughout the whole rs-matter codebase. All system clusters, Matter, transport, IM, DM, everything everything.

All done - it's not complete, as I said it's just in these specific classes where we're using atomic, so that we keep behavior (i.e. functionality usable across threads) even if it's not 100% complete (i.e. those Notification bits may need some work)

Leaves the state slightly better than it was before, and eliminates atomic usage (you were right, didn't make sense here)

It's a very small piece of #329, but acts as a good example & moves us forward

@gmarcosb gmarcosb marked this pull request as ready for review October 16, 2025 16:28
@gmarcosb gmarcosb requested a review from ivmarkov October 16, 2025 16:37
Copy link

PR #329: Size comparison from b4bfd38 to 4762a6b

Increases above 0.2%:

platform target config section b4bfd38 4762a6b change % change
linux dimmable_light rs-matter FLASH 2236232 2243640 7408 0.3
onoff-light rs-matter FLASH 2137800 2143256 5456 0.3
speaker rs-matter RAM 5528 5552 24 0.4
Full report (3 builds for linux)
platform target config section b4bfd38 4762a6b change % change
linux dimmable_light rs-matter FLASH 2236232 2243640 7408 0.3
RAM 42776 42800 24 0.1
onoff-light rs-matter FLASH 2137800 2143256 5456 0.3
RAM 42760 42784 24 0.1
speaker rs-matter FLASH 2209256 2209808 552 0.0
RAM 5528 5552 24 0.4

Copy link

PR #329: Size comparison from b4bfd38 to 4ece152

Increases above 0.2%:

platform target config section b4bfd38 4ece152 change % change
linux dimmable_light rs-matter FLASH 2236232 2243624 7392 0.3
onoff-light rs-matter FLASH 2137800 2143240 5440 0.3
speaker rs-matter RAM 5528 5552 24 0.4
Full report (3 builds for linux)
platform target config section b4bfd38 4ece152 change % change
linux dimmable_light rs-matter FLASH 2236232 2243624 7392 0.3
RAM 42776 42800 24 0.1
onoff-light rs-matter FLASH 2137800 2143240 5440 0.3
RAM 42760 42784 24 0.1
speaker rs-matter FLASH 2209256 2209792 536 0.0
RAM 5528 5552 24 0.4

Copy link
Contributor

@ivmarkov ivmarkov left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have two very small nits you can disregard and one slightly more important - the "let's not default to CriticalSectionRawMutex" one.

Now, if this is the scope of change that you meant by "I'll do a part of #258 here" - yes, I'm completely fine with that.

The trouble in #258 is mutex-ifying (under a single mutex + RefCell) the state of the Matter struct.

Copy link

PR #329: Size comparison from b4bfd38 to 87a8156

Increases above 0.2%:

platform target config section b4bfd38 87a8156 change % change
linux dimmable_light rs-matter FLASH 2236232 2241080 4848 0.2
Full report (3 builds for linux)
platform target config section b4bfd38 87a8156 change % change
linux dimmable_light rs-matter FLASH 2236232 2241080 4848 0.2
RAM 42776 42776 0 0.0
onoff-light rs-matter FLASH 2137800 2136504 -1296 -0.1
RAM 42760 42760 0 0.0
speaker rs-matter FLASH 2209256 2208208 -1048 -0.0
RAM 5528 5528 0 0.0

@gmarcosb gmarcosb merged commit 12141d0 into project-chip:main Oct 16, 2025
12 checks passed
@gmarcosb gmarcosb linked an issue Oct 16, 2025 that may be closed by this pull request
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Remove byteorder, strum, subtle, safemem, portable-atomic and possibly time from the dependency list Remove the dependency on portable-atomic

2 participants