{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreici6i4vwupev6dsvpnh2xwfpp33zjym3564pkcz35m2343wmzhsam",
    "uri": "at://did:plc:hqad6xwuzg7oqfmwylfkvqfm/app.bsky.feed.post/3miib4iwdg5x2"
  },
  "path": "/viewtopic.php?t=33281&p=271725#p271725",
  "publishedAt": "2026-04-02T02:36:22.000Z",
  "site": "http://forum.palemoon.org",
  "textContent": "Yeah, more to the point, I do think in some places our codebase are still very single-threaded and doesn't take advantage of multi-core architecture, and that's why the \"stupid half-busted e10s trick\" as I like to call it, still helps some of the more... umm, adventurous users with stuttering more than we'd like. I feel like better use of multithreading and scheduling threads would likely help mitigate the \"advantage\" of using the browser this way somewhat, but we have had to put most of our development effort into things like keeping up with web standards or dealing with regressions introduced by newer versions of things, so actually making the experience smoother or more responsive has taken a bit of a backseat.\n\nLike I can definitely imagine that trying to add more thread-level parallelism in the JS engine in particular would help, but there is some anxiety about making sure everything is wired up to handle that, and also that it's handled well/securely.\n\nEDIT: Looking at the comment above by Job, didn't we see some changes from Mozilla while we were implementing WebComponents that mentioned changing the way the Atoms are handled in order to allow for more stuff like this? It might be one of the patches G4JC either slipped in because it was a prerequisite for changes we needed, or one that was rejected for being out of scope, but this looks familiar...\n\n* * *",
  "title": "Platform Development • Re: e10s support question",
  "updatedAt": "2026-04-02T02:36:22.000Z"
}