-
Notifications
You must be signed in to change notification settings - Fork 55
Remove unnecessary deps #329
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
Conversation
PR #329: Size comparison from b4bfd38 to 651abce Increases above 0.2%:
Full report (3 builds for linux)
|
There was a problem hiding this 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.
@gmarcosb Looks quite nice! But I would not trust it until we have the dedicated guinea-pig executable. Which is compiled with - say - Standard Rust debug builds are |
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?
(this is in https://github.com/gmarcosb/rs-matter/blob/main/.github/workflows/size-check.yml) |
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 |
PR #329: Size comparison from b4bfd38 to 4e45cc3 Increases above 0.2%:
Full report (3 builds for linux)
|
Sounds like a plan 👍 Should just be a matter of updating the CLI in |
Heh. The "RAM" of the |
PR #329: Size comparison from b4bfd38 to 7dc00f9 Increases above 0.2%:
Full report (3 builds for linux)
|
PR #329: Size comparison from b4bfd38 to ed742a8 Increases above 0.2%:
Full report (3 builds for linux)
|
Will be doing a bit of #258 to eliminate atomic |
I suggest you reconsider. #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. |
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 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 |
PR #329: Size comparison from b4bfd38 to 4762a6b Increases above 0.2%:
Full report (3 builds for linux)
|
PR #329: Size comparison from b4bfd38 to 4ece152 Increases above 0.2%:
Full report (3 builds for linux)
|
There was a problem hiding this 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.
PR #329: Size comparison from b4bfd38 to 87a8156 Increases above 0.2%:
Full report (3 builds for linux)
|
Fixes #314