I have beel fiddling with SwiftUI and it has taken up a huge amount of CPU %. Has anybody else experienced this? It it takes forever to build. I think I have it confused.
My Xcode is shut down, but I still have two swift processes running at 98%.
Something wrong here....
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:
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:
I grouped a number of sections together, using Group. in another SwiftUI view, and that helped things considerably.
I had a ForEach in an HStack in a horizontal ScrollView in a VStack, which was using 100% CPU. Putting the whole thing inside a Group = 0% CPU.
Incredible the difference in CPU consumption from using a ForEach loop to a Group. Thank you
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.
source control caused the problemXcode -> Preferences -> Source Control uncheck Enable Source control. Then restart Xcode, everything will be fine