Sudden Drop in CPU Utilization in macOS App After Extended Operation

Thanks for the answer.

In fact, even when my app is working on other programs simultaneously after the contention, it feels smooth (I'm currently thinking that this is simply a difference in CPU usage). So it wouldn't be a good idea to intentionally induce contention, and thus low share, would it?

I think it's dangerous to approach the problem with this mindset, because a lower share simply feels "good". But even if I solve the contention problem, I'm also feel its hard to solve the high CPU utilization problem in more ways.

It's a tough problem, but at the same time, I feel like I need to solve the contention problem first.

Thanks for the good advice.

I've encountered another issue. Within Xcode, when checking via the CPU report, it indicates a decrease in usage. However, when observing through the activity monitor, there's no noticeable reduction. I'm curious as to why this might be the case.

However, after 3-4 hours of operation, the CPU utilization suddenly drops to around 10%.

From your text, it's unclear if this is a problem — do you see your app's performance significantly impacted in a way that you're concerned about? Also, if your app is expected to do a significant amount of work over a long stretch of time, it's possible you've reached a system thermal threshold, and the system is making adjustments to allow it to cool off. Without knowing much more about your situation here, this is a bit of speculation on my part. APIs like ProcessInfo.ThermalState can be helpful here.

I'm also wondering why the thread count in the picture goes into the 3000s after 3-4 hours. I'm also wondering if this is an issue with asynchronous processing.

You might be witnessing the thread number increasing, but not the overall active thread count, depending on how you use different concurrency APIs, like Swift Concurrency or Dispatch. The system may create and destroy threads over time, so you see this identifier going up over the hours for each new thread that the system creates, but it's also just an identifier. Whether or not this is a crucial problem is an "it depends" situation where the details in your code matter.

The analysis process through Profile in Instruments is also tricky in terms of catching the exact moment of a sudden change in CPU utilization.

What do you find tricky? You can let Instruments run for hours to capture the data, though the resulting trace file will be large. There are also features under File > Recording Options that let you record a rolling window of data, such as keeping only the most recent data of a set time interval that you can choose.

I'm looking for advice from people who have some experience with performance/memory optimization in iOS environments, not necessarily macOS.

If you remain stuck, this is a great use for a Technical Support Incident that's part of the Apple Developer Program. By using opening of those incidents, you'll be able to share your Instruments trace with an Apple Engineer — myself or some of my colleagues — and get deeper insights with the complete data you have available. The trace files collected by Instruments are large, so we can provide you with an upload location to share it with us privately. Further, if you have additional information or context that you can share privately that you've chosen not to share in this forum post, please include it in your TSI.