我们目前正在评估我们下一代公司范围的开发人员pc配置，并注意到一些非常奇怪的事情。
我们相当大的巨石 - 在我们目前的配置上有一个大约的构建时间。 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，对吗？
答案 0 :(得分：0)
经过近一年的试验，我们得出的结论是，确实是NTFS才是罪魁祸首。如果您有一个带有Linux主机的ntfs用户分区，则与all-windows-setup相比，您会得到一些相似的结果。
我们进行了gradle构建，eclipse内部构建，启动wildfly以及在多个设备上运行以数据库为中心的测试的基准测试。从Windows切换到Linux时，我们所有的基准测试始终显示出至少100％的速度提升（有时，Windows在现实世界基准测试中所花费的时间是Linux的3倍，某些人为基准测试所达到的速度是60！尤其是在笔记本电脑上，我们的噪音要小得多，因为完整版本的组合处理器负载要比Windows少得多。
我们的结论是，在过去的一年中从Windows切换到Linux。
关于并行化，我们意识到，这是某种形式的代码纠缠。解决这个问题有助于gradle和javac大量并行化构建（也可以查看gradle-composite-builds）