Jon*_*han 5 linux windows performance virtualbox javac
我们目前正在评估我们的下一代全公司开发人员电脑配置，并注意到一些非常奇怪的事情。
我们相当大的整体 - 在我们当前的配置上，构建时间约为。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，对吧？
经过近一年的实验，我们得出的结论是，作恶者确实是NTFS。如果您有一个带有 Linux 主机的 ntfs 用户分区，则与全 Windows 设置相比，您会得到一些相似的结果。
我们对 gradle-build、eclipse 内部构建、启动 Wildfly 以及在多个设备上运行以数据库为中心的测试进行了基准测试。我们所有的基准测试一致显示，从 Windows 切换到 Linux 时，加速至少为 100%（有时，Windows 在实际基准测试中花费的时间是 Linux 的 3 倍，一些人工基准测试的加速速度为 60！）。特别是在笔记本电脑上，我们体验到的噪音要少得多，因为完整构建的综合处理器负载比 Windows 低得多。
我们的结论是，在去年的过程中从 Windows 切换到 Linux。
关于并行化，我们意识到，这是某种形式的代码纠缠。解决这个问题有助于 gradle 和 javac 并行化构建（也可以查看 gradle-composite-builds）