Linked by Thom Holwerda on Mon 10th Jul 2017 18:27 UTC
Windows

This story begins, as they so often do, when I noticed that my machine was behaving poorly. My Windows 10 work machine has 24 cores (48 hyper-threads) and they were 50% idle. It has 64 GB of RAM and that was less than half used. It has a fast SSD that was mostly idle. And yet, as I moved the mouse around it kept hitching - sometimes locking up for seconds at a time.

So I did what I always do - I grabbed an ETW trace and analyzed it. The result was the discovery of a serious process-destruction performance bug in Windows 10.

Great story.

Thread beginning with comment 646546
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: just terrible...
by FlyingJester on Mon 10th Jul 2017 19:37 UTC in reply to "just terrible..."
FlyingJester
Member since:
2016-05-11

Or you could say that Chrome's poor thread safety, requiring separate processes, and lack of proper memory management in a 'burn the process and let the OS figure it out' has drawbacks.

Reply Parent Score: 1

RE[2]: just terrible...
by Megol on Mon 10th Jul 2017 19:40 in reply to "RE: just terrible..."
Megol Member since:
2011-04-11

Or you could say that Chrome's poor thread safety, requiring separate processes, and lack of proper memory management in a 'burn the process and let the OS figure it out' has drawbacks.


One could say that but it would be stupid.

Reply Parent Score: 5

RE[2]: just terrible...
by christian on Mon 10th Jul 2017 19:43 in reply to "RE: just terrible..."
christian Member since:
2005-07-06

Or you could say that Chrome's poor thread safety, requiring separate processes, and lack of proper memory management in a 'burn the process and let the OS figure it out' has drawbacks.


Unless I misread the article, this was Chrome's BUILD process creating lots of processes (compilers etc.)

Reply Parent Score: 1

RE[2]: just terrible...
by Carewolf on Mon 10th Jul 2017 19:50 in reply to "RE: just terrible..."
Carewolf Member since:
2005-09-08

It is not chrome it is the chrome build system, that by default launches a process per virtual core, and doesn't care about load. Though it wouldn't be a problem if W10 didn't have this performance issue on process teardown.

Reply Parent Score: 2

RE[2]: just terrible...
by TemporalBeing on Tue 11th Jul 2017 03:49 in reply to "RE: just terrible..."
TemporalBeing Member since:
2007-08-22

Or you could say that Chrome's poor thread safety, requiring separate processes, and lack of proper memory management in a 'burn the process and let the OS figure it out' has drawbacks.


While the author talks about Chrome builds, I highly doubt it's limited to the software he's specifically using since the issue is in the Windows OS portions of code, not application code.

Reply Parent Score: 2

RE[2]: just terrible...
by Lennie on Tue 11th Jul 2017 09:58 in reply to "RE: just terrible..."
Lennie Member since:
2007-09-22

Windows has always sucks at this. They've always preferred using threads.

But as we know (some only learned this many years later) using processes has a big advantage:

https://en.wikipedia.org/wiki/Privilege_separation

So making that fast is actually a really good idea.

Reply Parent Score: 2

RE[3]: just terrible...
by Megol on Tue 11th Jul 2017 11:46 in reply to "RE[2]: just terrible..."
Megol Member since:
2011-04-11

Windows has always sucks at this. They've always preferred using threads.

But as we know (some only learned this many years later) using processes has a big advantage:

https://en.wikipedia.org/wiki/Privilege_separation

So making that fast is actually a really good idea.


So why not do it right and use a microkernel?

Reply Parent Score: 2