Skip to content
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

receive_any: Use trailing_zeros to improve performance #50

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

showier-drastic
Copy link

@showier-drastic showier-drastic commented Dec 12, 2024

In current code, receive_any needs to do loop operation to iterate over memory buffer to check whether there's new data which can consume a lot of CPU time.

This code changes this operation to use trailing_zeros to get the first available message directly from NDAT register without any loops.

Thank you!

Thank you for your contribution.
Please make sure that your submission includes the following:

Must

  • The code compiles without errors or warnings.
  • All tests pass and in the best case you also added new tests.
  • cargo +stable fmt was run.
  • (No, but it does not relate to my code) cargo +stable clippy yields no warnings.
  • Your changes were added to the CHANGELOG.md in the proper section.
  • You add a description of your work to this PR.
  • You added proper docs (in code, rustdoc and README.md) for your
    newly added features and code.

In current code, `receive_any` needs to do loop operation to iterate
over memory buffer to check whether there's new data which can
consume a lot of CPU time.

This code changes this operation to use `trailing_zeros` to get the first
available message directly from NDAT register without any loops.
@showier-drastic showier-drastic requested a review from a team as a code owner December 12, 2024 12:10
@Ironedde
Copy link
Contributor

Hello @showier-drastic!

Nice to see you showing interest in this crate.
And sorry for the late response.

I am not the original implementer of this code, but I'll try the best I can to be useful.
I know that this looping might seem a bit excessive, but it was (probably) made this way to enable highest priority (lowest ID) messages to be handled first, regardless of which buffer the message is placed in.

Since I haven't had any practical experience with the dedicated buffers, but instead have only used the FIFOs, do you mind providing some insight into your use-case and how you would like to use these buffers?

The reason I'm asking is because I do see the validity of having a configurable priority order, by which I mean the lowest buffer (in contrast to the lowest ID) gets handled first, but I am not sure if we want to eliminate the possibility for native ID ordering (like now) as well.

Maybe we could introduce some config option to specify the way we want the Iterator for RxDedicatedBuffer to function when reading out messages.

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.

2 participants