我使用双系统启动：我在 Linux 中编写代码（这个问题在 Arch 和 Debian 10 中都存在），我在 Windows 10 中玩游戏。我的电脑基于 Ryzen Threadripper 2950 构建，它有 128GB 的 RAM。从理论上讲，它的表现并不差。
我注意到我的同事可以在 10 分钟内完成某些操作，而我需要 30 分钟，尽管理论上他们的机器“更慢”。起初我以为这是文件系统相关的问题，因为这些任务通常以npm install或开头docker build。不过我在 ext4 和 btrfs 上都看到了这个问题，所以我放弃了这是我的文件系统中的一个错误的想法。
大约三个月前，我开始记录某些任务的时间，发现它不只是慢。它很慢并且越来越慢。然后我注意到清除 CMOS 可以将其恢复到以前的（快速）速度。几天前，我注意到性能明显下降，这发生在我周末在 Windows 上玩游戏之后。我相信更新是在某个时候安装的。
有问题的应用程序是vim。它太慢了，以至于按键进入缓冲区的顺序是乱序的。我输入“container”，然后会看到“cotannrie”。没有考虑 cmos-fix，我分析了缓慢的部分，如下所示：https://stackoverflow.com/a/12216578
我没能找到有问题的插件，但最终想起了 cmos-fix。清除 cmos 后，一切又恢复正常。然后，为了好玩，我运行了一个类似的配置文件。以下是 vim 配置文件前后差异的屏幕截图：
左边的列表示在分析会话期间调用该行 vimscript 的次数，中间的列表示其平均执行时间。清除主板 CMOS 可使速度提高 2 到 10 倍——这足以让我重新开始工作。但令我惊讶的是，速度提高似乎在各个操作之间或多或少是均匀分布的。即使是在分配变量等简单操作中也是如此。
我只能每隔几个月复制一次，但下次我想收集更多有用的前后细节。所以我的问题是：我下一步应该怎么做才能缩小这个问题的范围，我应该收集哪些数据才能让任何人相信这是一个真实存在的问题？
我目前的理论是，这与 Windows 更新有关。我相信更新程序会执行以下操作：
- 设置系统固件以启动 Windows EFI 分区
- 安装更新
- 重启
- 我没有修复固件，让它回到我离开的地方，而是让它指向 Windows
每次我安装全新的 Linux，它都能运行大约一个月，然后 Windows 更新就会破坏它。（但我仍然可以通过在启动时按 F11 并选择正确的分区来启动它）。启动问题可能无关紧要，但它们证明了 Windows 在完成安装更新后不会自行清理。所以问题是，什么别的是否清理失败？我如何找到证据？
答案1
我注意到诸如sysbench无法测量性能下降的实用程序，但在使用时很容易发现vim，所以我写了一个基准脚本在 中打开一个文件vim，以缓慢的方式（jjjj……）滚动浏览，并跟踪其花费的时间。
我只是想获得一个一致的基线，这样当下一次 Windows 更新发布时，我就可以进行比较，但数字不会保持不变。之后挣扎我发现测试执行的速度要么是 10 秒，要么是 40 秒，这取决于我是否从 Windows 重新启动进入 Linux，或者我是否从 Windows 关闭电源，然后打开电源进入 Linux。
重新启动时，NVIDIA GeForce GTX 1080 Ti 会“记住”以前的操作系统对其的配置情况。 无论那是什么，它都是扰乱我的性能基线的隐藏变量，如果你在操作系统之间关闭电源，它就会被遗忘。
在 Linux 中安装专有 nvidia 驱动程序并重启两次后，我的基准测试始终在 10 秒内完成（第一次重启后仍然需要 40 秒，因为它记住了之前启动时的虚假配置）。
我目前的理论是，这npm是有问题的，因为他们所做的所有那些繁琐的动画 docker build仍然是一个谜。
我确实发现了奇怪的与 efi 相关的变化的证据，这些变化仅当我让 Windows 启动时才会发生（比如我的 efi 分区的内容发生变化，或者 /dev/nvmeXn1p1 磁盘改变其 X 值）但我目前不知道它们是否与我的性能问题有关。
至于 Windows 更新。我认为，在清除后第一次启动时提示进入 uefi 设置足以偏离我的日常习惯，以至于我总是错过“按 F11 选择启动”时间窗口——这意味着每次我清除 CMOS 时，我也会先启动到 Windows，吸收图形驱动程序的优点，然后重新启动到 Linux。
答案2
我不确信这与 Windows 更新有关。
我有两台双启动机器，我从 UEFI USB 驱动器启动 Linux，而 HDD 中有一个 Windows 10。每当我在 Windows 中使用“重新启动”选项时，我都会在重启后返回 Windows 系统。如果我使用“关机”选项，我会在打开计算机几秒钟后返回 Windows。
我能够按下 UEFI 启动设备选择器（F11 等）或甚至进入 SETUP（删除等）的唯一方法是物理地将 SATA 连接器从 Windows HDD 上拆下。然后我可以重新配置启动选项，但只要我插入任何更新的 Windows 10 HDD，SETUP 就会重新配置为将 Windows 启动管理器重新设置为第一个启动选项。这种情况发生在多个主板上，并且有多个 Windows 10 副本/版本。
有时，擦拭电源（拔下电源线并等待很长时间 - 或者清除 CMOS）可以“修复”此行为。
因此，虽然这与 Windows 更新本身没有直接关系，但在我看来，一些最近的 Windows 10 更新正在接管内存（RAM）甚至其他存储（BIOS / UEFI 缓存等）。
这是我根据自己的经验得出的理论。很抱歉，由于声誉低下，我无法发表评论。