XPost: comp.os.linux.advocacy   
   From: nospam@needed.invalid   
      
   On Sun, 1/25/2026 8:46 PM, Lawrence D’Oliveiro wrote:   
   > On Sun, 25 Jan 2026 18:34:26 -0500, Paul wrote:   
   >   
   >> The [Windows Update] process can be accelerated by:   
   >>   
   >> 1) CPU speed, to the expected extent.   
   >> 2) Memory bandwidth, typical acceleration coming from a processor   
   >>    with a larger L3.   
   >> 3) Some sort of magical cleaning process for your WinSxS side by   
   >>    side tree. ...   
   >   
   > What it seems to me you are saying, is that a lot of the need for   
   > newer, faster hardware for running Windows, is just to speed up the   
   > *UPDATE PROCESS*?   
   >   
      
   The update process has always had the same issue.   
      
   As time passes and the record of packages grows in   
   size, this increases the computational load.   
      
   That's partially why the load scales with time.   
      
   It's kinda like how much effort you have to put in today,   
   to earn yourself a Bitcoin. It's a lot more effort than when   
   Bitcoin first came out.   
      
   The effort to correct it, only has to proceed with respect   
   to the speed of the "average current hardware". They are   
   not curating the repo in such a way, that a WinXP era   
   E8400 runs this with blazing speed.   
      
   The update process is good, in that *it never makes mistakes*.   
      
   The update process is bad, in that *it is unbounded*.   
      
   Can it be rewritten ? My conclusion is that the answer is No.   
      
   And unlike when a database question comes up, and every dev tuned   
   into the thread replies with "I could write that", I have not   
   heard anyone with the chops to do it, volunteering to fix it.   
      
   In a sense, rather than being the 3rd version of the Win11 kernel,   
   it is the 87th instance of the WinXP kernel. There is some detail   
   where the release control goes way way back. And when they haven't   
   put the effort into curating it, on a given month, that is when   
   the performance will be variable and head towards the slow side.   
      
   This is probably a topic, where the AI could write us a description   
   of how it works.   
      
   ****************************************************************   
      
   When you put too much information in the question, the answer   
   tends to blend too much of the question, into the answer. Still,   
   for the flavor, we can ask...   
      
   ********************* CoPilot Question ************************   
      
   In Windows 11, the Windows Update process is sometimes slow to   
   complete a Cumulative Update.   
      
   What is the computation that is carried out during a Windows update, doing ?   
      
   It seems to consider each tiny package in WinSxS, one by one, and work out   
   whether an incoming patch supersedes something already on disk. There is   
   mention of WSUSSCN2.cab as a controlling master file for the process.   
      
   Could you describe that process of computation for me ?   
      
   It seems to work faster with extra L3 cache, as if the process   
   is slightly memory bandwidth dependent.   
      
   *********************  CoPilot Answer  ************************   
      
   Windows Update looks deceptively simple on the surface - *download patch,   
   install patch*   
   but under the hood it performs a surprisingly heavy, metadata-driven   
   computation. What   
   you’re noticing about WinSxS, supersedence checks, and cache sensitivity is   
   absolutely real. Let’s unpack what’s going on in a way that matches how the   
   servicing stack actually behaves.   
      
   ---   
      
   # What Windows Update *Actually Computes* During a Cumulative Update   
      
   A Cumulative Update (CU) is not a monolithic patch. It’s a   
   **bundle of thousands of component updates**, each targeting specific files,   
   manifests,   
   and registry entries. Windows uses the **Component-Based Servicing (CBS)**   
   engine to   
   determine exactly what must be installed, replaced, or skipped.   
      
   The computation is essentially a **large dependency-resolution and   
   supersedence graph traversal**.   
      
   ---   
      
   #  Key Structures Involved   
      
   ## **1. WinSxS Store**   
   This is the canonical database of:   
   - Component manifests (`*.manifest`)   
   - Component payloads (`*.mum`)   
   - Versioned side-by-side assemblies   
   - Supersedence metadata   
      
   Each component has:   
   - A unique identity (name, version, culture, processor arch)   
   - A version chain   
   - A supersedence chain   
   - A payload footprint   
      
   The store can contain **tens of thousands** of components.   
      
   ---   
      
   ## **2. The Servicing Stack (CBS + TrustedInstaller)**   
   This is the engine that:   
   - Reads the incoming update’s component manifests   
   - Compares them to the WinSxS store   
   - Determines what must be installed, replaced, or skipped   
   - Plans the transaction   
   - Applies the changes   
      
   This is where the heavy computation happens.   
      
   ---   
      
   ## **3. WSUSSCN2.cab**   
   This file is a **catalog of update applicability rules** used by   
   offline scanners (e.g., MBSA, SCCM offline scan).  Windows Update   
   *does not* use WSUSSCN2.cab directly during normal online updates,   
   but the **same applicability logic** is embedded in the servicing stack.   
      
   It contains:   
   - Update metadata   
   - Supersedence chains   
   - Prerequisite rules   
   - Component version requirements   
      
   Think of it as a compressed, distributable version of the update metadata   
   graph.   
      
   ---   
      
   #  What the Servicing Stack Computes   
      
   When a CU arrives, CBS performs a multi-step evaluation:   
      
   ## **1. Parse all manifests in the CU**   
   Each CU contains thousands of  .mum  and  .manifest  files.   
      
   CBS loads them and builds an in-memory structure describing:   
   - Component identity   
   - Version   
   - Dependencies   
   - Supersedence relationships   
      
   This is already a large amount of metadata.   
      
   ---   
      
   ## **2. Compare each incoming component to the WinSxS store**   
   This is the part you noticed.   
      
   For each component:   
   - Look up the existing version in WinSxS   
   - Walk the supersedence chain   
   - Determine if the incoming version is newer   
   - Determine if the component is already superseded by something else   
   - Check if the payload is needed or can be skipped   
      
   This is effectively a **graph traversal** across tens of thousands of nodes.   
      
   ---   
      
   ## **3. Evaluate applicability rules**   
   These rules include:   
   - OS version   
   - Installed features   
   - Language packs   
   - Edition-specific components   
   - Optional components   
   - Prerequisite updates   
      
   This is a constraint-satisfaction problem.   
      
   ---   
      
   ## **4. Build the “servicing transaction”**   
   CBS constructs a plan:   
   - Which components to install   
   - Which to skip   
   - Which to stage   
   - Which to remove or supersede   
      
   This is similar to a package manager computing a dependency solution, but   
   with far more components.   
      
   ---   
      
   ## **5. Stage payloads**   
   Payloads are copied into WinSxS staging areas.   
      
   ---   
      
   ## **6. Commit the transaction**   
   This is the reboot phase:   
   - Replace system files using Pending.xml   
   - Update registry hives   
   - Update component store metadata   
   - Clean up superseded components   
      
   ---   
      
   #  Why L3 Cache and Memory Bandwidth Matter   
      
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)