Xcode 11调试器非常慢-一个已知的问题？

由于我更新到了最新的 Xcode 版本11.0(11A420a) ，因此调试非常缓慢和繁琐。

编辑: 更新到11.1 GM (11A1027)之后，问题还是一样。

编译一个项目并在模拟器或设备上运行它是没有问题的。然而，当达到一个断点时，Xcode 或多或少变得不可用:

  • 程序执行在到达断点时立即停止。然而，Xcode 需要最多30秒来显示代码窗口中的位置，还需要一分钟左右来加载变量视图的内容(它显示断点处可用变量的值和状态)。
  • 如果我使用 进来或者 过来特性，那么执行下一个步骤需要一分钟，加载变量需要另外一分钟。

我在一台3.2 GHz i7和32GB 内存的 Mac mini 2018上运行 Xcode。我以前在同一台机器上使用过 Xcode 10，没有任何问题。

搜索“ Xcode slow”会显示大量的线程和可能的解决方案。从我作为 iOS 开发者的那些年里，我知道 Xcode 从来都不是最快和最稳定的程序。但是从来没有像现在这么糟糕。

不幸的是，所有已知的技巧(重新启动 Xcode 或 Mac、清理项目、清理 Xcode 库文件夹等等)都没有任何效果,

所以最大的问题是:

这是 Xcode 11中已知的问题吗? 有什么已知的解决方案吗

21505 次浏览
小开

I've seen some performance improvements when using the Whole versus Incremental Compilation behavior. Additionally running on Mojave and Catalina should both be showing performance issues. Specifically since the Canvas preview and other new features require more CPU intensity than the last version of Xcode, I would expect Mojave performance to be lower when using Xcode 11 (as it's not optimized for this version of the OS). With Catalina being in Beta, I'd expect to see additional issues as well. I haven't taken specific measures other than the eye-test. The initial run on Whole Compilation is slow but seems to get better thereafter.

Quick help states:

Summary

This setting controls the way the Swift files in a module are rebuilt. * Incremental: Only rebuild the Swift source files in the module that are out of date, running multiple compiler processes as needed. * Whole Module: Always rebuild all Swift source files in the module, in a single compiler process. Declaration

SWIFT_COMPILATION_MODE Value Type

Enumeration (String)

小开

Have you tried running Xcode in safe mode? It's not ideal, but this was the only way I could get it to run efficiently. That is until the recent Catalina update where my device is no longer detected in safe mode. So I'm back to square one now.

小开

Well I had the same problem and recently figured out that I just forgot to disable diagnostics for my scheme

enter image description here

Open your run configurations -> Manage schemes -> Edit scheme -> Run -> Diagnostics tab

小开

I've found the same problems in two different cases:

1) the app is not launched by Xcode, i.e. the flag "Wait for executable to be launched" is set inside the Info panel of the Scheme Run settings;

2) the option "Launch due to a background fetch event" is selected in the scheme settings (but this is not the default)

Xcode option position

Xcode 11.2.1 (11B500)

小开

In my case (XCode 11.x, MacOS 10.15.2) I've found that the extreme debugger slowness is only triggered if I single-step while another single-step operation is in progress, i.e. I press the step button too quickly. My current workaround is to avoid doing that.

Pure speculation but perhaps it's triggered by XCode/LLDB trying to service multiple breakpoints concurrently? Try removing all breakpoints but one and see if that helps things.

In case it's relevant: I mostly work with C++ in XCode, with a little Obj-C here and there. I don't use Swift at all at present.

小开

Please try to uncheck: Parallelize Build on each target in Edit Scheme. It 'll save time to build If your project has many targets.

Edit Scheme:

enter image description here

小开

I've been dealing with this forever and finally figured it out. It was these lines in my ~/.lldbinit file:

break set -F '-[UIView layoutIfNeeded]' -c '!(BOOL)[NSThread isMainThread]' -L objc
break set -F '-[UIView(AdditionalLayoutSupport) updateConstraintsIfNeeded]' -c '!(BOOL)[NSThread isMainThread]' -L objc

I commented those lines out and now it's almost as fast as without the debugger!

小开

I had 238 unused breakpoints set. When I deleted them, it's fast again (even with diagnostics turned on.)

小开

For me, deleting ~/.lldb solved this problem.


提交答案