linux - Java 中特定于操作系统的构建性能

Question

我们目前正在评估我们下一代全公司范围内的开发人员电脑配置，并注意到一些非常奇怪的事情。

我们相当大的单体应用 - 在我们当前的配置下，构建时间大约为。 4.5 分钟(没有测试，只是编译)。

对于我们的下一代配置，我们升级了几个组件。适度增加处理器的频率和 IPC，将 CPU 内核数量增加一倍，并从小型 SATA SSD 切换到额定 >3GBps 的 NVMe SSD。此外，下一代配置从 Windows 7 切换到 Windows 10。

在执行第一个测试时，我们注意到构建时间几乎相同(4.3 分钟)，这比我们预期的改进要少得多。

在我们的实验过程中，我们曾尝试在 Windows 主机上运行的虚拟 Linux 机器中运行构建过程。在旧配置 (Windows7) 上，我们看到构建时间从 4.5 分钟减少到约 3.7 分钟，在 Windows 10 主机上，我们看到构建时间从 4.3 分钟减少到 2.3 分钟。我们已经排除了病毒扫描之类的可能性。

我们对这些结果感到相当惊讶，并试图找到另一种解释，而不是对不同操作系统的一些近乎宗教和侮辱性的陈述。

所以问题是:我们在配置 Windows 机器时可能做错了什么，使得速度几乎是在同一台 Windows 主机上虚拟化运行的 Linux 的一半？尤其是当所有的硬件进步似乎都被从 Windows 7 切换到 10 时吞噬掉了。

另一个问题是:我们如何才能让 javac 进程使用更多的内核，因为现在，使用 Hotspot JDK 8 我们最多可以看到构建真正使用了两个内核。我读过有关 sjavac 的内容，但这似乎是一个相当实验性的功能，仅适用于 OpenJDK9 之后的版本，对吧？

Answer 1

经过将近一年的试验，我们得出结论，NTFS 确实是作恶者。如果您有一个带有 linux 主机的 ntfs 用户分区，与全 Windows 设置相比，您会得到一些类似的结果。

我们对 gradle-build、eclipse 内部构建、启动 wildfly 以及在多个设备上运行以数据库为中心的测试进行了基准测试。当从 Windows 切换到 Linux 时，我们所有的基准测试始终显示至少 100% 的加速(有时，Windows 在现实世界基准测试中花费的时间是 Linux 的 3 倍，一些人工基准测试有 60 倍的加速!)。尤其是在笔记本电脑上，我们体验到的噪音要小得多，因为完整构建的处理器总负载比 Windows 少得多。

我们的结论是，在去年的过程中从 Windows 切换到 Linux。

关于并行化，我们意识到，这是某种形式的代码纠缠。解决这个问题有助于 gradle 和 javac 大量并行化构建(也可以查看 gradle-composite-builds)