search

touchlab / xcode-kotlin

Kotlin Native Xcode Plugin
https://touchlab.co/xcodekotlin
Apache License 2.0
1.15k stars 47 forks source link

Xcode debug speed #23

Closed LNeway closed 2 years ago

LNeway commented 4 years ago

The speed of the debug is very slow ? any advice ? my xcode version is 11.6 (11E708)

kpgalligan commented 4 years ago

More detail? What's slow? What data is being displayed?

LNeway commented 4 years ago

xcode is slow to resolve vars and step by step debugging (just for Kotlin native code)

kpgalligan commented 4 years ago

Are they simple vars? Arrays? Objects? A video would help too.

On Thu, Aug 6, 2020 at 10:49 AM 刘伟 notifications@github.com wrote:

xcode is slow to resolve vars and step by step debugging (just for Kotlin native code)

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/touchlab/xcode-kotlin/issues/23#issuecomment-669975372, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAQWIBJAK3KPVMLT4OW4S3R7K7HHANCNFSM4PWTAOAQ .

-- Kevin Galligan https://twitter.com/kpgalligan

LNeway commented 4 years ago

you can get the video by this link

they are complex instance

thanks

kpgalligan commented 4 years ago

Yeah, that's the old lldb formatter. I'll check into it, but they shouldn't show the summary string like that. That's the default out of the box from Kotlin/Native. It recursively walks the whole object graph, which is why it's slow. Not sure how the Xcode plugin has that version, but it's wrong. debugger

For a quick fix, find konan_lldb.py and edit to_string to simply return "..." for the whole method.

https://github.com/touchlab/xcode-kotlin/blob/master/Kotlin.ideplugin/Contents/Resources/konan_lldb.py#L296

LNeway commented 4 years ago

thanks for you help

The speed increase is obvious ~

so what is the next improvement ? the debug speed is still slower than the Object C code

kpgalligan commented 4 years ago

That's a long story. I don't think it'll ever be quite as fast, but as long as it's usable, that's a start. About a year and a half ago I took the stock python file and did a bunch of optimizations on it, then submitted that to Jetbrains. They took some of them, but not all. I need to fix the current issue, then see if there are any other optimizations that would make sense, but I want to be able to use the file provided by Jetbrains if possible, so we don't need to maintain a fork of it. We'll see.

kpgalligan commented 2 years ago

closing this. We're going to be syncing our lldb script with the JB one more frequently going forward, and looking for ways to improve the step and data access speeds.