You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm using GDB 7.10 from NDK r11b for Windows 64-bit and I've noticed that -thread-info command takes a lot of time for processing compared to other GDB MI commands - more than one second on Nexus 7 2013 device running API21 and bit less on a newer hardware. I suppose that's due to the fact that it also reports the top stack frame for each thread of execution. That's unfortunate, because sometimes front-end needs to get thread names really quick, and 1 second delay hurts UX. Maybe there's a faster way to query for a thread names?
Call -thread-info for each thread id in a loop is even slower, though.
I don't think there's much we can do about this, maybe file an upstream bug/feature request? The gdb documentation suggests for a related operation that you should cache the results. If you use async, I think you should be able to notice and query threads for their name as soon as you get a thread-created notification.
I'm using GDB 7.10 from NDK r11b for Windows 64-bit and I've noticed that
-thread-info
command takes a lot of time for processing compared to other GDB MI commands - more than one second on Nexus 7 2013 device running API21 and bit less on a newer hardware. I suppose that's due to the fact that it also reports the top stack frame for each thread of execution. That's unfortunate, because sometimes front-end needs to get thread names really quick, and 1 second delay hurts UX. Maybe there's a faster way to query for a thread names?Call -thread-info for each thread id in a loop is even slower, though.
The text was updated successfully, but these errors were encountered: