I am evaluating a Lenovo desktop before it becomes the standard issue desktop for Gecko developers. The desktop is 2 x E5-2637v4 CPUs at 3.5 GHz. It's a nice beefy machine that can build Firefox faster than my i7-6700K 4.0 GHz desktop (mostly due to more cores). For reasons I haven't yet explained, the Lenovo desktop is significantly slower at running configure on Windows 10. On my i7-6700K, configure completes in ~133s. On the Lenovo, it is ~179s. Yes, the Lenovo is running a slower CPU clock *and* a prior generation architecture. But the wall time difference seems much greater than what I'd expect. Here is a breakdown in the times between the two machines: i7-6700K E5-2637v4 main configure 59.5s 57.3s (the time reported by the line after "creating ./config.data") js/src complete 75.2s 80.3s jemalloc complete 110.0s 148.6s finished 132.9s 179.2s jemalloc seems to be responsible for most of the relative slowness on the Lenovo desktop. What really gets me is that the main configure runs about the same speed on both machines but js/src and jemalloc are substantially slower. Huh? This machine is physically in the SF office and I'd be happy to set up remote desktop access to anyone who wants it. Setting needinfo on me to look into this further, as I'm supposed to be prioritizing stylo work. I figured I'd file the bug in case anyone has any theories they want me to test.

It'd probably be useful to grab ETW traces while running configure on both machines. Bruce Dawson has a GUI to make this easier: https://github.com/google/UIforETW

note that non main configures run in parallel, so one of them can have an influence on the others.

I was running Process Monitor and Process Explorer on the slow machine and nothing obvious stood out to me. Full ETW traces using UIforETW are usually next on my "profile why it's slow" checklist. FWIW, I did run the jemalloc configure in isolation and it takes ~60s every time. It's a bit faster if it has a populated config.cache. But if I nuke that file between runs, ~60s every time.

This turned out to be CPU underclocking via highly conservative power management on Xeons.