Open Hexlord opened 1 month ago
@llvm/issue-subscribers-lldb
Author: Aleksandr Knorre (Hexlord)
What platform is this on? Any chance the project is open source and can be built to reproduce this?
If you run log enable dwarf all -f /tmp/lldb.log
, then reproduce the issue on lldb17 and lldb18 and attach both logs, there might be some useful info about how much work we're doing up-front parsing debug-info. Though that's just a guess. Maybe someone else has other ideas for useful logs to collect here
What platform is this on? Any chance the project is open source and can be built to reproduce this? If you run
log enable dwarf all -f /tmp/lldb.log
, then reproduce the issue on lldb17 and lldb18 and attach both logs, there might be some useful info about how much work we're doing up-front parsing debug-info. Though that's just a guess. Maybe someone else has other ideas for useful logs to collect here
If you are generating logs for this, be sure to include the -T
option to log enable
since that will give us timestamps. Also, if you have a tool that can sample a process while it is running, taking samples of the fast and slow operations and comparing them to see what extra work is being done can also often be helpful.
There is a major difference in performance when debugging with lldb-18/lldb-19 over lldb-17, where our app (game) startup and teardown times increase almost tenfold (from under a second to multiple seconds).
Could be related to the slow symbol lookup in lldb-18 bug #64582 but it seems the fix is live in lldb-18/lldb-19 that we tested, so must be something else.
Not sure how we could help with resolving this, the repro steps is to just "lldb-18" , then "run" and observe the different startup time compared to lldb-17.
Tested on lldb version 18.1.3 (slow perf), lldb version lldb 17.0.6 (fast perf).