[Lldb-commits] [lldb] Fix dap stacktrace perf issue (PR #104874)

[via lldb-commits]

================
@@ -3111,17 +3115,20 @@ void request_stackTrace(const llvm::json::Object &request) {
     // This will always return an invalid thread when
     // libBacktraceRecording.dylib is not loaded or if there is no extended
     // backtrace.
-    lldb::SBThread queue_backtrace_thread =
-        thread.GetExtendedBacktraceThread("libdispatch");
+    lldb::SBThread queue_backtrace_thread;
+    if (g_dap.enable_display_extended_backtrace)
+      queue_backtrace_thread = thread.GetExtendedBacktraceThread("libdispatch");
     if (queue_backtrace_thread.IsValid()) {
       // One extra frame as a label to mark the enqueued thread.
       totalFrames += queue_backtrace_thread.GetNumFrames() + 1;
     }
 
     // This will always return an invalid thread when there is no exception in
     // the current thread.
-    lldb::SBThread exception_backtrace_thread =
-        thread.GetCurrentExceptionBacktrace();
+    lldb::SBThread exception_backtrace_thread;
+    if (g_dap.enable_display_extended_backtrace)
+      exception_backtrace_thread = thread.GetCurrentExceptionBacktrace();
----------------
jeffreytan81 wrote:

I don't have time to work on this. My goal is to quickly fix the performance regression and unblock the business.

Frankly, the original PR should have been reverted initially, as it introduced the regression.

The reasonable engineering process should involve landing this PR to disable the performance regression. Then, the author of the original PR can fix it in the desired way.

https://github.com/llvm/llvm-project/pull/104874