Michael Krussel
11/08/2024, 8:45 PMautoreleasepool
. I assume this makes it so Kotlin releases its reference hold when the lambda ends.
Is there a concern with creating a lot of objects in Kotlin that are not getting passed to Swift/Objective-C code? I wouldn't want to try using autoreleasepool
all over the place in the common code.
What about cases going the opposite, where Swift/Objective-C is passing objects to Kotlin. Is there any special concern that should be done there. I had an interface called from Kotlin and implemented in Swift that returned an object from Swift where the Swift code would no longer care about it. I think this was getting called like 800 times based on an UI action. I was finding that the UI would lock up after hitting the button like 20 times (about a second between clicks). I've changed this so the button does different logic and that the interface is not called again, but I could still see this being a problem in other use cases. I haven't fully researched if it was those objects causing the problem or if it was other objects that get created based on them, but everything else stays in the Kotlin memory system. Also interested in knowing if it is worth the effort to try and move the implementation of the interface into Kotlin to avoid garbage collection problems.
I also had issues where I was allocating a large object in an implementation of a Objective-C protocol and returning it from the function. I wanted to use autoreleasepool
to clean up the memory being used, but since I needed to return it from the autoreleasepool
I don't think it did anything.
I'm using Kotlin 1.9.24 with default memory manager settings. I'm working on upgrading to 2.0.21.
I didn't seem to be experiencing high memory usage, just CPU usage.Michael Krussel
11/18/2024, 2:58 PMRohit Talati
11/18/2024, 4:59 PM