Swift Charts is incapable of plotting 2k data points and handling animation even with the vectorized Line plot API. Trying to do this will cause microhangs or hangs.

Once again thanks for your prolific efforts! I filed FB15092842 For those that follow, here is an example of the trace that led me here. You can use the Time Profiler in Instruments to see that GCD is doing something, but I am not aware of any other tools to help track this problem down.

I have looked far and wide for the cause of the GCD hang. It was Xcode all along. queueDebuggingEnabled = "No" should be the default choice. That option should be off unless debugging a dispatched work issue. It really hurts performance. It can eventually cause the GCD kernel thread explosion issue without any reasonable way to debug it with Xcode or Instruments. After scouring documentation, rewatching all of the WWDC sessions, attempting to guess solutions, and crawling the forums, I greatly appreciate this answer as I have truly sunk a great deal of time trying to appease the GCD. I realize the feature is super cool that it works, but it has not been useful for debugging any of my applications as you typically only have a couple DispatchQueues to juggle. Here is an appropriate reproduction: Use CoreBluetooth with Combine to plot data in real-time with Swift Charts without blocking the main thread. Run for hours, it will happen as long as you are dispatching on and off the main queue. It may only take an hour before it is unusable if your notification rate is high enough. In my experience with several of the frameworks, a real-world bluetooth streaming application would be of great benefit to the acceptance testing suite. There are several long existing hangs and degradations that would be exercised by including such a test in the standard testing procedures. Once again thanks for your accurate answer Eskimo!

With Instruments, I measured hangs event when using the vectorized API on the order of 50-150ms when using relatively small number of data points (500-2000). In order to get reasonable performance, I implement downsampling with LTTB off the main thread before attempting to plot too many points. If you write your own drawing with CoreGraphics, handling 10K can be done with reasonable UX, except the GPU will kick on when drawing the points (or line) and overheat the iOS device.

Was the bug ever filed? The same thing happened to me two years later.

I mis-clicked and now an off-topic response is the accepted reply ... There is no way to undo fix this according to https://developer.apple.com/forums/thread/662659

I am also experiencing these hangs on tensorflow-metal==0.5.1 with tensorflow-macos==2.8.0 and python 3.9.13 installed via the recommended Apple miniforge documentation. I had to downgrade from tensorflow 2.10.0 because Apple’s coremltools hasn’t been updated to support past 2.8.0 yet. I had to downgrade tensorflow-metal as well since the current version crashes on import. I have a MacBook Pro M1 Max with macOS 12.6. It seems like there should be a set of versions that work together. The basic package versions that need to coexist are tensorflow-deps tensorflow-macos tensorflow-metal and coremltools. I am still looking for something that works.