{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreifm7s52iw55ew4wjgxlc25v7n7mqdo25bja65yrv42c5tfc2b2iei",
    "uri": "at://did:plc:hqad6xwuzg7oqfmwylfkvqfm/app.bsky.feed.post/3mkpbzhon2b22"
  },
  "path": "/viewtopic.php?t=33382&p=273026#p273026",
  "publishedAt": "2026-04-30T08:08:55.000Z",
  "site": "http://forum.palemoon.org",
  "tags": [
    "https://learn.microsoft.com/en-us/windo ... ystem_info",
    "https://repo.palemoon.org/MoonchildProd ... .cpp#L3072"
  ],
  "textContent": "> This calculation gives a disproportionate increase in threads to the number of cores. On a modern processor with 12 cores, we will get 33% (16 versus 12) more threads than cores, and on a processor with 4 cores, the increase in threads is 100% (8 versus 4). Maybe it’s worth using a different calculation principle, for example, doubling the number of threads per core?\n\nWell, actually I turned up something interesting here.\n\nhttps://learn.microsoft.com/en-us/windo ... ystem_info\n\nhttps://repo.palemoon.org/MoonchildProd ... .cpp#L3072\n\nEssentially, if I'm reading the code correctly, the function called to define cpuCount actually calls the sysinfo function that returns the number of **logical** processors, not the number of physical CPU cores like we were all thinking. So, at least on Windows for sure, cpuCount would actually be 8 on my system, not 4. Which... makes the function name kinda misleading. You'd think they'd call it \"logicalProcessorCount\" or something similar to clarify that it's not the number of CPUs, but the number of execution contexts that is getting reported here. Which of course means that threadCount doesn't refer to anything meaningful, other than just being a very unfortunate name especially next to cpuCount, since it just refers to an arbitrary number of software threads that have absolutely nothing to do with \"threads\" in the CPU sense.\n\nIf this is right... does that mean this was using 12 parse threads before my old quad core started having an application freeze with a fresh profile, and backing off to 11 was what made it rock solid stable for me? It was definitely handling more parse threads than the number of logical processors would imply, in that case. This was the only function in the codebase with the same name as what it was calling, so I assume it was this one... though it might actually pay to see if we can get it to tell us what it's reporting for cpuCount here with some kind of print statement or logging just to make sure my analysis is correct.\n\n* * *",
  "title": "Platform Development • Re: The browser hang with 0 CPU load.",
  "updatedAt": "2026-04-30T08:08:55.000Z"
}