Home News Process Termination Bug in Windows 10 is affecting developers making their code build very slow

Process Termination Bug in Windows 10 is affecting developers making their code build very slow

by Harikrishna Mekala

Bruce Dawson is a programmer working for Google uses a 24-Core CPU, 64 GB of RAM and High i/O SSD but he was not able to move his mouse. Your PC comes crumbling to an immediate halt, and mouse action becomes difficult. Fighting toward what seems to be an approaching system crash, you type-in your trusty “CTRL-ALT-DELETE” and start up task manager… to see only 50% CPU/RAM utilization. Why, was everything stopping?

You get confused and walk out of the office, that’s why you don’t work for Google. As Google programmer Bruce Dawson, there remained only one reasonable way to handle this: “So I did what I always do – I took an Event trace and analyzed it. The result was the finding of a serious process-destruction performance bug in Windows 10.”

What does that imply, exactly? It indicates when a process “stops” or closes, it need go into a single thread to manage this. In this critical component of the OS which each process must ultimately participate in, Windows 10 is truly single threaded.

To be honest, this is not a common issue an end user would face. But developers usually spawn lots of methods and close them just as often. They utilize high-end multicore CPUs to speed this forward. Bruce writes that in his situation, his 24-core CPU only got things worse, as it really caused the build process to produce more build processes, and therefore, even extra, had to close. And because they all go into the same single threaded queue, the OS crunches to a halt during this process, and performance peak is never realized.

In the Words of Bruce:

Amdahl’s law says that if you throw enough cores at your problem then the parts that cannot be parallelized will eventually dominate execution. When my work machine has been heavily used for a few days this serialization issue gets bad enough that process-shutdown becomes a significant part of my distributed build times – and more cores can’t help with that. In order to get maximum build speeds (and if I want to move my mouse while doing builds) I need to reboot my machine every few days. Even then my build speeds are not as fast as they should be, and Windows 7 starts to look tempting.

Take your time to comment on this article.

You may also like