SwiftUI Gobbling Up CPU

I'm using macOS 10.14.5, and Xcode 11, beta 3. I'm not using the beta version of Catalina.

Without knowing more details about what you're working on, whether or not you're using the preview pane, etc, it is difficult to offer any useful resonses. However, based on my own experiences:

1. Live previews **** down as much system resources as a simulator, I don't use them often
2. If you interupt build processes often, sometimes the compiler process fails to die, peek at your activity monitor and check for hung processes
3. complex views, or views with any kind of hand coded layout logic, can take the compiler quite some time to try to resolve into a view type that is less opaque than 'some View'. Make sure extract subviews where you can as this seems to be a file scoped issue.

I grouped a number of sections together, using Group. in another SwiftUI view, and that helped things considerably.

I've seen the compiler eat up to 400% CPU (swift and SourceKitService processes). This often comes from complex views or incorrect use of things like @Binding, things often difficult to detect. A limitation has been introduced in Beta 3 where XCode will shut itself down if compilation takes too long. I guess this will be iron out progressively.

In the meantime, it's best to break down views into smaller pieces and statement progressively and run build often.

I'm building a form with a button that brings up a modal sheet. I found that if I modify one of the form's @State variables in the dismiss closure of the .sheet, SourceKitService goes nuts. Specifically, it consumes memory without limit - I've seen over 90 GB in activity monitor - and does not terminate once it's in that state even if Xcode will. I've also seen a few zombies named swift hang around.

I don't think (in my case) that the issue is complexity of the form, as it's divided into sections and no section has more than 4 elements; no element has more than three views in it. I can print the content of the var in the dismiss closure and all is copacetic, but even something as benign as thatvar = [] leads to disaster.

My guess is that the type system is stuck in a loop, but all I really know is that by starting to comment things out I finally isolated the chunk that triggers the problem. Watching for processes running away with memory usage in activity monitor was the best tool I had to know if I was on the path to success or not.

I filed feedback demonstrating the problem. If you can isolate the trigger, you might want to do so too. Maybe just in any case file one.

Exactly parallels what I see. When you say incorrect use of @Binding, what do you mean? (In my case, the trigger to disaster involves a @State fed into another view, so there may be similarities).

I've been running into this lately. I had SourceKitService eating 162G of memory (on an iMac with 32G of RAM). I feel like it is triggered by confusion of the compiler in certain cases. Out of frustration, and wanting to do something different, I got into a shell, and did "kill -1" to the SourceKitService. To my great delight, it stopped and restarted, and is now using a reasonable amount of memory.

Dunno if this fixed things for all time, probably not, but it's nice to know there is some possible workaround.

Running into this with xcode 13 on Monterrey. Shut down Xcode, and the cpu was still being consumed to the point that you could hear the machine. Using top found that a process called "swift-frontend" was the culprit. Did a "kill " and that took care of that.

• In my case, I found Xcode source control caused the problem

• To fix this problem Xcode -> Preferences -> Source Control uncheck Enable Source control. Then restart Xcode, everything will be fine