I'm having an issue with my compose app and too mu...

# compose-desktop

[gbaldeck]

I'm having an issue with my compose app and too much CPU being used. There should be less than 1% of the CPU used but it is up to 20% in some cases and other apps slow down quite a bit. I do not believe this is a problem with compose or coroutines, but it may be a problem with how I am using them. The below links with line numbers show the chain of how I'm using a task that runs in a background coroutine. Does anyone know how I can optimize this?
1. Line 45 of https://github.com/recursiveg87/Grim-Locations/blob/master/src/main/kotlin/io/grimlocations/ui/view/EditorView.kt
2. Line 37 of https://github.com/recursiveg87/Grim-Locations/blob/master/src/main/kotlin/io/grimlocations/ui/viewmodel/event/EditorEvents.kt
3. Line 81 of https://github.com/recursiveg87/Grim-Locations/blob/master/src/main/kotlin/io/grimlocations/ui/viewmodel/reducer/EditorReducers.kt
4. Line 95 of https://github.com/recursiveg87/Grim-Locations/blob/master/src/main/kotlin/io/grimlocations/ui/viewmodel/reducer/EditorReducers.kt
5. LaunchEffect wrapper I used in item 1. https://github.com/recursiveg87/Grim-Locations/blob/master/src/main/kotlin/io/grimlocations/framework/util/LaunchedEffect.kt
To give some more background on what I'm trying to do here. I am detecting if an app is running, and if it is I check if a file was changed, if it was then I load the file's contents into the compose app.

[Zach Klippenstein (he/him) [MOD]]

Pro tip: you can link to specific lines in GitHub

[Zach Klippenstein (he/him) [MOD]]

First off, startGDProcessCheckLoop creating its own root scope is a red flag. Defeats the purpose of calling it from a launched effect, breaks structured concurrency, introduces memory and other resource leaks. It should be a suspend function. And the coroutine started by launched effect is already running on the main dispatcher.

[Zach Klippenstein (he/him) [MOD]]

That launched effect wrapper is a bit of smell too. It takes a key for a reason, and in this case you probably want to pass in vm as the key since the caller could pass a different instance in at any time, and if they did then youd leak the launched coroutine from the last one.

[Zach Klippenstein (he/him) [MOD]]

Have you run your program through a profiler? That will be a much easier way to figure out what’s eating all your cpu than trying to figure it out by hand

[gbaldeck]

Hi, thanks for the replies. Passing the vm as the key is a great idea and I'll keep that in mind. But in this case there is only ever one instance of that vm created by my vm manager. So I don't believe that is effecting it. The coroutine scope you mentioned I can get rid of. And no I haven't used a profiler and don't have experience with any. I will take a look around for one.

[olonho]

IDEA got rather cool Async Profiler, see https://www.jetbrains.com/help/idea/async-profiler.html

[christophsturm]

java flight recorder is also pretty cool and comes with the jdk

[theapache64]

@olonho but that's for only ultimate version, right? 😭

[gbaldeck]

@Zach Klippenstein (he/him) [MOD] I'm not sure the underlying mechanics, but your suggestions fixed the issue. It now doesn't go above 2% CPU. Thanks for your help