search

dronecan / gui_tool

MIT License
23 stars 23 forks source link

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

Open jensenr30 opened 1 year ago

jensenr30 commented 1 year ago

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 commented 12 months ago

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 commented 12 months ago

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 commented 11 months ago

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 commented 10 months ago

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 commented 10 months ago

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 🤣