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

CAN bus monitor lags and consumes excessive CPU resources when recording frames #35

Open
jensenr30 opened this issue Jun 15, 2023 · 5 comments

Comments

@jensenr30
Copy link

jensenr30 commented Jun 15, 2023

In the CAN bus monitor window, when I press the "record" button, as CAN frames build up in the log, the performance of the app gradually declines. Refresh rates gradually slow to less than 1 screen refresh per second. CPU usage increases to 100% of a single CPU core. When the CAN bus monitor is not recording, the CPU usage drops to less than 10%.

Linux 6.2.5-060205-generic #202303110831 SMP PREEMPT_DYNAMIC Sat Mar 11 13:57:40 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
Ubuntu 23, i5-13600k, 32 GB DDR4 @ 3200 MT/s

If I find some free time one of these weekends, I would like to try contributing to this project by investigating these performance issues. Which sources files should I look at to improve CAN bus monitor performance?

@thealienthing
Copy link

thealienthing commented Jul 6, 2023

I'd like to second this. I'm experiencing the same issues on Windows 10 where the Bus Monitor is SUPER laggy. My CPU usage is at 12% on average. Memory is not too much of an issue but dumping messages from RAM to disk occasionally would be really nice.

@jensenr30
Copy link
Author

jensenr30 commented Jul 6, 2023

The issue seems to be related to rendering the list of CAN messages. When I press the "Pause Updates" button, the GUI becomes responsive again and the CPU usage goes down to about 7-10 % usage of one CPU core. Maybe the performance could be improved by only rendering the messages that fit into the current view of the list.

@thealienthing
Copy link

I was wondering the same thing. Suppose this is one of those moments where we're supposed to roll up our sleeves and do it lol.

@David-OConnor
Copy link

David-OConnor commented Aug 23, 2023

I considered writing a tool like this in Rust (C/C++ would be fine too). I'm suspicious Python is not the right tool for the job. I restart the tool frequently, and/or dump the messages to help.

@thealienthing
Copy link

As a workaround, I find the best approach is to set up filters, like filter messages intended for a particular node, THEN click the capture button. Capture messages until you've got enough data. Then pause and then stop capturing. This approach allows me to keep the monitor open for long stretch without needing to close it before it seizes up 🤣

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

No branches or pull requests

3 participants