search

SteffeyDev / atemOSC

Control ATEM video switchers over the network with OSC messages
http://www.atemosc.com
202 stars 32 forks source link

High background CPU usage #222

Closed tdcox closed 2 years ago

tdcox commented 3 years ago

v4.1.4 is showing high idle CPU usage.

With no messages being sent to atemOSC, I am seeing 90% CPU utilisation on an i9 Macbook Pro. This is enough to keep the CPU at full clock and generates a lot of excess heat, meaning that fans are on continuously.

The problem is not seen at startup, but seems to increase from near zero at the start, rising about 3% as each message is received. If I invoke /atem/macros/0/run multiple times in rapid succession, for example, the app flips to 90% utilization and sticks there until restarted.

The app runs each event, but I notice that scrolling of the message window becomes intermittently unresponsive.

I am not routing feedback messages anywhere, so it's possible that these are not being discarded cleanly.

SteffeyDev commented 3 years ago

Interesting, I'll have to see if I can reproduce. It does sound like a classic memory leak, which might be related to my conversion to ARC recently.

cybrgloom commented 2 years ago

Hi, not sure if this is exactly the same (let me know if I should start another issue), but I'm seeing similar unusual high CPU use on version 4 compared to version 3 on my system (13" Macbook Pro 2019). When there is no messages, CPU use is somewhat similar to version 3, however once messages are sent, CPU use jumps to around 50% and stays there consistently. While with version 3, CPU use would never really go above 2% or so, regardless of activity.

That is quite a lot of difference.

For now it's not problem running version 3 for me does what I need, except I'd love dark mode ;))) (but more importantly would like to help future proof the software at some point i'd probably need to go version 4). Let me know if I can send you anything logs, system info, setups. I haven't had time to let it run for long periods (am currently developing a performance so frequent edits), I don't know if it would increase over time but I could test that if you would like.

MBPR13" 2019, macos Catalina 10.15.7, Ableton Live 11.0.5., LiveGrabber OSC tools, network is cabled ethernet

SteffeyDev commented 2 years ago

Hi @cybrgloom, I'm just getting back to this project. I'm curious, does it matter what message you send? Or does every message make it jump to 50%? When I run locally, I am unable to reproduce.

@tdcox Are you still having the issue? I'm unable to reproduce your issue as well, what MacOS version are you running? And what year is your MBP?

tdcox commented 2 years ago

@SteffeyDev Since reporting, I have upgraded to Big Sur and ATEM Software Control 8.6.2. I am currently seeing a constant utilisation of around 40% on an i9 (2018) MBP. To put this in context, it's about double the utilisation of the streaming video conference (1080p/50) I currently have running.

I haven't looked at the code, but if you are polling, you may need to look at sleeping for a greater percentage of time for more efficiency?

SteffeyDev commented 2 years ago

Ok, I haven't upgraded to Big Sur yet but I might be able to test on a machine that does. What does your configuration look like inside atemOSC? And does it change at all when you are sending messages?

OSC works over UDP, so no polling there. Not sure how the SDK works under the hood to talk to the switcher, but I couldn't optimize that anyways.

tdcox commented 2 years ago

@SteffeyDev Not sure what you are asking for? I just have one defined switcher with a specified IP address and 'Connect automatically' is enabled (although this doesn't actually work in practice, if the switcher is turned off and on again whilst atemOSC is running).

cybrgloom commented 2 years ago

Hi Peter, thanks for following up. I just gave it a test again; it jumps to approx 50% CPU as soon as messages starts flowing, regardless which ones, but i didn't test extensively... I only use the command "program", but tried "preview", instantly same result. As soon as messages flow, CPU use jumps from below 1% to 50%. And it stays at that CPU use forever until I quit the app, also when nothing is happening (no messages being sent for hours). This was on this system: Macbook Pro Air 2018, macOS 10.15.7, Ableton Live 11.0.5

I also tested on a Mac Mini I've gotten since the first report. I can see the same there; when launching the app, CPU use is 0,5%. As soon as messages starts flowing, CPU use jumps to 25% on this system. Mac Mini M1 (2020), macOS 11.5, Ableton Live 11.0.5

As mentioned version 3 works flawlessly for me. Would it help you if I sent the Ableton set? (For this test I made a stripped down project with only the AtemOSC track)

On Tue, Sep 21, 2021 at 3:20 AM Peter Steffey @.***> wrote:

Hi @cybrgloom https://github.com/cybrgloom, I'm just getting back to this project. I'm curious, does it matter what message you send? Or does every message make it jump to 50%? When I run locally, I am unable to reproduce.

@tdcox https://github.com/tdcox Are you still having the issue? I'm unable to reproduce your issue as well, what MacOS version are you running? And what year is your MBP?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/SteffeyDev/atemOSC/issues/222#issuecomment-923500055, or unsubscribe https://github.com/notifications/unsubscribe-auth/ASIBYGSXPGYDFMBQUE26MKDUC7MWLANCNFSM453FBRZQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

SteffeyDev commented 2 years ago

I was able to identify the issue, looks like I missed a check so it was re-drawing the log table very often. I'll fix this in the next release, which I'm trying to get out this week.

cybrgloom commented 2 years ago

Great, thanks for the update. Looking forward to giving it a spin once it's out, and let you know how it performs.

On Thu, Nov 11, 2021 at 12:36 AM Peter Steffey @.***> wrote:

I was able to identify the issue, looks like I missed a check so it was re-drawing the log table very often. I'll fix this in the next release, which I'm trying to get out this week.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/SteffeyDev/atemOSC/issues/222#issuecomment-965840349, or unsubscribe https://github.com/notifications/unsubscribe-auth/ASIBYGVFIAWTODUSMJ6PWU3ULL6YJANCNFSM453FBRZQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

SteffeyDev commented 2 years ago

Released in 4.2.0, let me know if that doesn't fix it for you

tdcox commented 2 years ago

Seems good, thanks! Jumps up to about 30% when sent a flurry of events, then after 20 secs or so, falls back to 0.5% at idle.

cybrgloom commented 2 years ago

Gave 4.2.0 a spin now, tested it for a few hours, here's what I found:

Version 4.2

-When the app is "active", receiving commands, AtemOSC CPU use is at approx 50% if the app is unhidden (*). CPU stays at 50% as long as the atemOSC receives messages. When messages stop, CPU use drops to 0,2% after a few seconds and stays there. Once messages arrive, CPU use jumps immediately up to 50%. So improvement on idle, but the 50% CPU use is tenfold the usage of version 3 for active commands.

-However if the app is active and HIDDEN, not displayed on screen, CPU use is at 4% when receiving messages! This is approximately same as for AtemOSC

  1. Is this because the log isn't being drawn? I really don't need to see the log.

( with unhidden I mean it is active on-desktop, not necesserily visible to the eye, it can be hidden by another app being in front of it, but it is "visible in the GUI", if you use mission control to show all open apps, you will see it. With hidden *I mean that the app is hidden with the Hide command, it is not anywhere on the desktop, mission control will not show it)

Version 3

This version uses consistently 3% CPU when active, regardless if hidden or not, and 0,2% when idle. So for now I'll keep staying with this version, it just works. :)

Let me know if i can help in any way, i'd be happy to test updates or help you figure out what the issue can be.

On Mon, Nov 15, 2021 at 4:49 PM tdcox @.***> wrote:

Seems good, thanks! Jumps up to about 30% when sent a flurry of events, then after 20 secs or so, falls back to 0.5% at idle.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/SteffeyDev/atemOSC/issues/222#issuecomment-969045277, or unsubscribe https://github.com/notifications/unsubscribe-auth/ASIBYGRW6GHLVHZUHKUIW53UMETZ7ANCNFSM453FBRZQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.