7 ms·

Windows update is probably one of the worst engineered parts of the OS. On my quad core i7 with a dedicated GPU it used to take anywhere from 45 mins to two hou

by chmln 8y ago

Windows update is probably one of the worst engineered parts of the OS. On my quad core i7 with a dedicated GPU it used to take anywhere from 45 mins to two hours to install the big updates and around 30 mins for smaller ones. Not only they take ridiculously long, eventually you are forced to update upon booting in or shutting down. Never mind that you turned on your PC to, you know, get something done potentially urgently. In contrast, I can upgrade my months-stale arch Linux box in under 2-3 minutes. After seeing how much better the same hardware can run, there is no going back.

codetrotter 8y ago
The Windows Update system is engineered so that individual updates can be selected/deselected without affecting the ability to install other updates. The slowness of Windows Update, as I understand, is related to this fact. However, that being said, Windows Update for me as a user that would apply all updates anyway, was unbearably slow, and a big part of the reason that I switched to Linux and FreeBSD years ago and never looked back. I guess for enterprises that want to deselect certain updates for various reasons relating to their setup, Windows Update is probably a great selling point. I still don’t get why it has to be so slow for the default case where all updates are applied though.
- danShumway 8y ago
  > The Windows Update system is engineered so that individual updates can be selected/deselected without affecting the ability to install other updates. This could be me being completely ignorant of the details, but doesn't Linux have the same thing? I can individually apply package updates, even mess with dependencies -- but my computer updates quickly and doesn't require multiple restarts during the process. Usually, unless I'm updating the kernel itself, I don't even need to restart. What are they doing that's even more granular than Linux's update process?
  - tomnipotent 8y ago
    Only this was 1st party updates from Microsoft only, but it felt like you were getting updates from a hundred 3rd party packages.
    - chris_wot 8y ago
      Well, here's a fun fact for Windows 7: Microsoft at one point decided that they would allow people to roll forward and roll back updates at-will, and even move to an update at a point-in-time in its entirety if necessary. Obviously, this is rather insane and takes up a gigantic amount of disk space, and wasn't something they ever implemented. They must have realised this, so they built a facility into their DISM.exe utility to remove all updates that were superseded by the service pack (the switch is /spsuperceded). DISM.exe was released in Windows 7 SP1. Note that there has never been, and never will be, a Windows 7 SP2, because Microsoft decided to go with the rolling update schedule. What this means, however, is that /spsuperceded will never work as they have never actually gotten to a second service pack. It appears to me that Microsoft must have forgotten the original plan for clearing out old and useless patch files from SxS, because they rather surreptitiously introduced a new option into the disk cleanup wizard to remove old Windows Updates (to get to it, you need to elevate to admin via UAC in the GUI). This removes the old updates. I have literally had systems with around 6-8GB of old Windows Update files. The biggest issue is that you think they are deleted, but it appears that Microsoft actually removes the updates after you reboot. I've had one system that took an hour to reboot as it was removing so much junk. I had a friend who had an even worse system, and he had to leave it overnight... Here's another fun fact (not sure if it's fixed in Windows 10...) but the WinSxS folder is where system files are kept. NTFS does a symbolic link to these folders back to the System32 folder. The problem is that the metadata is updated in one location only, and so if you check the WinSxS folder and the System32 folder, you'll see different file sizes for each folder.
      - anticensor 8y ago
        > NTFS does a symbolic link to these folders back to the System32 folder. It creates hard links, not link symbolically.
- praseodym 8y ago
  Microsoft actually stopped offering invidiual updates two years ago, citing high complexity and slow update scan times as problems. Instead, they moved to monthly rollup patches that supersede all previous updates. https://techcommunity.microsoft.com/t5/Windows-for-IT-Pros-Migrated/Further-simplifying-servicing-models-for-Windows-7-and-Windows-8/ba-p/166772 https://techcommunity.microsoft.com/t5/Windows-for-IT-Pros-M...
cm2187 8y ago
What I don’t understand is why can’t they just simply replace the binaries and reboot. I am sure 99.9% of pc owner must not apply hotfixes or updates selectively. They could make those fast, and keep the slow process for the 0.1% who need this level of engineering.
- ocdtrekkie 8y ago
  Linux is a file system based OS, that works. Windows is a database based OS (the registry), just replacing the files often does not work.
  - pbhjpbhj 8y ago
    Can you expand on that, it doesn't make sense; are you saying databases inherently take a helluva lot longer than file systems to update ... file systems are databases ...
  - acdha 8y ago
    The correct way to describe it is that POSIX filesystems allow you to replace open files but Windows does not, so they had to queue updates until the boot process guarantees that nothing is using them. The POSIX approach makes it easy to install updates without rebooting but opens you to weird failures if a process loads things during an update and gets the new library A and old library Z. This is generally a much easier problem to handle.
    - anticensor 8y ago
      Correct way to solve that would be adding a new privileged Windows API call which ignores file locks and lies to other applications.
      - acdha 8y ago
        It’s been awhile but I thought that would complicate the way they load DLLs, not to mention the potential impact on legacy code which was doing something unsafe but would no doubt be spun as Microsoft unfairly breaking someone’s security kludge or dubious extension. Not something which can’t be handled but increasing the cost/risk perception. The big thing, though, is that they had a lost decade or so where the stack-ranking system heavily favored new features over improving existing code. Unless this was such a problem that it became a senior management priority I doubt anyone was jumping at touching it.
ezoe 8y ago
Not only that, Windows 10 requires multiple reboots during the OS upgrade, then it still requires some processing on the first user log-in after the upgrade. I have no idea how MS implemented the OS upgrade process this bad.
- romed 8y ago
  The only sensible way to update Windows is in a virtual machine hosted by another operating system, so the block caches don't get dropped by the reboots. When operated in this manner you an actually blow through a huge backlog of updates in no time.
  - yjftsjthsd-h 8y ago
    I'm confused, so just to clarify: You're saying that Windows on a virtual machine updates faster than Windows on bare metal? (I'd believe it, mind; reminds me of how some programs perform better on wine)
    - romed 8y ago
      Oh yes. WAY faster. All that grinding that windows goes through when it starts? Doesn’t happen in a VM because the blocks are cached already in memory by the host OS.
  - ezoe 8y ago
    That's hilarious.
blattimwind 8y ago
Windows Update is based on packages, which can be installed or not installed and depend on other packages and also conflict with packages. Unlike Linux packages, these packages act more like ... patches, I guess. I think Windows Update spends most of its CPU time on building and solving a big dependency graph.
- pbhjpbhj 8y ago
  How is that different to apt, it also has to solve dependencies for packages. Using slapt-get (Slackware version of apt-get) back in the day was quite the revelation after manually solving dependencies.
  - blattimwind 8y ago
    > How is that different to apt, it also has to solve dependencies for packages. Because it is way more complicated than apt: https://docs.microsoft.com/en-us/windows/deployment/update/how-windows-update-works https://docs.microsoft.com/en-us/windows/deployment/update/h...
    - yjftsjthsd-h 8y ago
      Is that more complicated? There's a lot of dark in there, but the general steps look comparable. And even if they did over engineer it to their own detriment, I'm not sure how that's supposed to give me more sympathy unless are solving problems that other package managers can't handle, which might be true but certainly isn't obvious to me.
      - Someone 8y ago
        I think apt-get installs packages, Windows Update applies patches. In Windows, can have individual updates to a library that fix bugs b1, b2, respectively b3. If so, you can install eight different variants of that library. If, later, a fix for bug b4 is released, its installer must be able to handle each of those variants. The installer also allows you to roll back any of those patches (example: patch b1, patch b3, patch b2, roll back b1, patch b3, patch b1 again) In practice, it’s impossible to handle that combinatorial explosion, so you get updates that require b1 to b3 to be fixed, that require service pack x, etc. However, the system still is designed to handle that. It sort-of must, given that Microsoft occasionally releases updates that it hasn’t tested on all possible hardware configurations, but that (may) solve a specific problem (https://blogs.technet.microsoft.com/mrsnrub/2009/05/14/gdr-qfe-ldr-wth/ https://blogs.technet.microsoft.com/mrsnrub/2009/05/14/gdr-q... is dated, but, I think, still illustrates the problem)
ocdtrekkie 8y ago
Is it using an SSD? Your graphics card is irrelevant. Most of your processor is irrelevant. If you use Windows 10 on a classic hard drive, you're going to have a bad time.
- acdha 8y ago
  SSD doesn’t matter much, either. It’s single-thread CPU bound in very inefficient code.
- mikhailt 8y ago
  I have a Samsung 970 Pro, which is NVMe m.2 SSD. It still took an hour to install the feature update like 1809. I believe someone mentions that feature updates like 1809/1803/etc are not actual patches based on current install, it is a complete OS reinstall, which explains the slow install.
  - Joeri 8y ago
    You used to have to reinstall windows every few years because it slowed down over time. I guess microsoft thought it would be convenient if they did that for us.
  - Schlaefer 8y ago
    The 1809 update took ten minutes on an average notebook with SSD here. MS did some serious work in the last releases to reduce the offline time for updates. See e.g. https://insider.windows.com/en-us/articles/were-listening-to-you/ https://insider.windows.com/en-us/articles/were-listening-to...
- chmln 8y ago
  Yes, the laptop always had an SSD and I know about the difference an SSD can make in terms of overall performance. However, the same comparison holds. I have an older backup PC in the basement with a hard drive, and it still takes just a few minutes to update in the background on Linux. Windows on that machine was simply unusable.
- PSZD 8y ago
cmurf 8y ago
My vague understanding is there's some kind of inode lock on in-use libraries, and only a reboot releases them. Therefore files can't really be overwritten. New files (and inodes) are written elsewhere, and then moved into place as part of the reboot. Two things I don't understand: why updates are so slow; and why the updating can't be done out of band. Seems like it could be done either with hardlinks or using VSS, so that it's safe to do as a background process rather than effectively kicking the user off their own system for the entire duration. Both hardlinks and VSS have been around forever on NTFS. While ReFS supports volume snapshots (but not hardlinks), its rollout as a replacement for NTFS appears stalled, only being recommended for specific use cases that aren't the general purpose use case (system disk).
- rincebrain 8y ago
  1) The deleting in-place is just a different default than on e.g. Linux - both can let you delete/rename/etc files underneath it, but Windows defaults to making you explicitly set a property to permit this in your open() call equivalents, while Linux requires you explicitly lock things to prevent this. 2) Updates can be slow for a bunch of reasons. One of them is that the WU agent as shipped in e.g. Win7 SP1 had some nasty O(n^2) or worse operations that got fixed in [1] and later. One of the reasons the monthly rollups versus itemized bits were an enhancement is, if your install for each update is NUMUPDATES* O(start transaction + do install of update bits + swap into place + end transaction) , removing all but one of the start and end transactions is a nice speedup. As far as using hardlinks and VSS to stage and swap updates into place...that is a thing that WU does already, and has done for quite some time. ReFS also makes me sad because it has so much potential, but they rolled it out without being able to used for many use cases, so it's probably gonna stall and die. [1] - https://support.microsoft.com/en-us/help/3161647/windows-update-client-for-windows-7-and-windows-server-2008-r2-june-20 https://support.microsoft.com/en-us/help/3161647/windows-upd...
maskull 8y ago
Yea, a fan in my laptop was failing and I mostly noticed it on Patch Tuesday.
chis 8y ago
This comment is totally unrelated to the article.

by chmln 8y ago

codetrotter 8y ago

The Windows Update system is engineered so that individual updates can be selected/deselected without affecting the ability to install other updates. The slowness of Windows Update, as I understand, is related to this fact. However, that being said, Windows Update for me as a user that would apply all updates anyway, was unbearably slow, and a big part of the reason that I switched to Linux and FreeBSD years ago and never looked back. I guess for enterprises that want to deselect certain updates for various reasons relating to their setup, Windows Update is probably a great selling point. I still don’t get why it has to be so slow for the default case where all updates are applied though.

danShumway 8y ago
> The Windows Update system is engineered so that individual updates can be selected/deselected without affecting the ability to install other updates. This could be me being completely ignorant of the details, but doesn't Linux have the same thing? I can individually apply package updates, even mess with dependencies -- but my computer updates quickly and doesn't require multiple restarts during the process. Usually, unless I'm updating the kernel itself, I don't even need to restart. What are they doing that's even more granular than Linux's update process?
- tomnipotent 8y ago
  Only this was 1st party updates from Microsoft only, but it felt like you were getting updates from a hundred 3rd party packages.
  - chris_wot 8y ago
    Well, here's a fun fact for Windows 7: Microsoft at one point decided that they would allow people to roll forward and roll back updates at-will, and even move to an update at a point-in-time in its entirety if necessary. Obviously, this is rather insane and takes up a gigantic amount of disk space, and wasn't something they ever implemented. They must have realised this, so they built a facility into their DISM.exe utility to remove all updates that were superseded by the service pack (the switch is /spsuperceded). DISM.exe was released in Windows 7 SP1. Note that there has never been, and never will be, a Windows 7 SP2, because Microsoft decided to go with the rolling update schedule. What this means, however, is that /spsuperceded will never work as they have never actually gotten to a second service pack. It appears to me that Microsoft must have forgotten the original plan for clearing out old and useless patch files from SxS, because they rather surreptitiously introduced a new option into the disk cleanup wizard to remove old Windows Updates (to get to it, you need to elevate to admin via UAC in the GUI). This removes the old updates. I have literally had systems with around 6-8GB of old Windows Update files. The biggest issue is that you think they are deleted, but it appears that Microsoft actually removes the updates after you reboot. I've had one system that took an hour to reboot as it was removing so much junk. I had a friend who had an even worse system, and he had to leave it overnight... Here's another fun fact (not sure if it's fixed in Windows 10...) but the WinSxS folder is where system files are kept. NTFS does a symbolic link to these folders back to the System32 folder. The problem is that the metadata is updated in one location only, and so if you check the WinSxS folder and the System32 folder, you'll see different file sizes for each folder.
    - anticensor 8y ago
      > NTFS does a symbolic link to these folders back to the System32 folder. It creates hard links, not link symbolically.
praseodym 8y ago
Microsoft actually stopped offering invidiual updates two years ago, citing high complexity and slow update scan times as problems. Instead, they moved to monthly rollup patches that supersede all previous updates. https://techcommunity.microsoft.com/t5/Windows-for-IT-Pros-Migrated/Further-simplifying-servicing-models-for-Windows-7-and-Windows-8/ba-p/166772 https://techcommunity.microsoft.com/t5/Windows-for-IT-Pros-M...

cm2187 8y ago

What I don’t understand is why can’t they just simply replace the binaries and reboot. I am sure 99.9% of pc owner must not apply hotfixes or updates selectively. They could make those fast, and keep the slow process for the 0.1% who need this level of engineering.

ocdtrekkie 8y ago
Linux is a file system based OS, that works. Windows is a database based OS (the registry), just replacing the files often does not work.
- pbhjpbhj 8y ago
  Can you expand on that, it doesn't make sense; are you saying databases inherently take a helluva lot longer than file systems to update ... file systems are databases ...
- acdha 8y ago
  The correct way to describe it is that POSIX filesystems allow you to replace open files but Windows does not, so they had to queue updates until the boot process guarantees that nothing is using them. The POSIX approach makes it easy to install updates without rebooting but opens you to weird failures if a process loads things during an update and gets the new library A and old library Z. This is generally a much easier problem to handle.
  - anticensor 8y ago
    Correct way to solve that would be adding a new privileged Windows API call which ignores file locks and lies to other applications.
    - acdha 8y ago
      It’s been awhile but I thought that would complicate the way they load DLLs, not to mention the potential impact on legacy code which was doing something unsafe but would no doubt be spun as Microsoft unfairly breaking someone’s security kludge or dubious extension. Not something which can’t be handled but increasing the cost/risk perception. The big thing, though, is that they had a lost decade or so where the stack-ranking system heavily favored new features over improving existing code. Unless this was such a problem that it became a senior management priority I doubt anyone was jumping at touching it.

ezoe 8y ago

Not only that, Windows 10 requires multiple reboots during the OS upgrade, then it still requires some processing on the first user log-in after the upgrade. I have no idea how MS implemented the OS upgrade process this bad.

romed 8y ago
The only sensible way to update Windows is in a virtual machine hosted by another operating system, so the block caches don't get dropped by the reboots. When operated in this manner you an actually blow through a huge backlog of updates in no time.
- yjftsjthsd-h 8y ago
  I'm confused, so just to clarify: You're saying that Windows on a virtual machine updates faster than Windows on bare metal? (I'd believe it, mind; reminds me of how some programs perform better on wine)
  - romed 8y ago
    Oh yes. WAY faster. All that grinding that windows goes through when it starts? Doesn’t happen in a VM because the blocks are cached already in memory by the host OS.
- ezoe 8y ago
  That's hilarious.

blattimwind 8y ago

Windows Update is based on packages, which can be installed or not installed and depend on other packages and also conflict with packages. Unlike Linux packages, these packages act more like ... patches, I guess. I think Windows Update spends most of its CPU time on building and solving a big dependency graph.

pbhjpbhj 8y ago
How is that different to apt, it also has to solve dependencies for packages. Using slapt-get (Slackware version of apt-get) back in the day was quite the revelation after manually solving dependencies.
- blattimwind 8y ago
  > How is that different to apt, it also has to solve dependencies for packages. Because it is way more complicated than apt: https://docs.microsoft.com/en-us/windows/deployment/update/how-windows-update-works https://docs.microsoft.com/en-us/windows/deployment/update/h...
  - yjftsjthsd-h 8y ago
    Is that more complicated? There's a lot of dark in there, but the general steps look comparable. And even if they did over engineer it to their own detriment, I'm not sure how that's supposed to give me more sympathy unless are solving problems that other package managers can't handle, which might be true but certainly isn't obvious to me.
    - Someone 8y ago
      I think apt-get installs packages, Windows Update applies patches. In Windows, can have individual updates to a library that fix bugs b1, b2, respectively b3. If so, you can install eight different variants of that library. If, later, a fix for bug b4 is released, its installer must be able to handle each of those variants. The installer also allows you to roll back any of those patches (example: patch b1, patch b3, patch b2, roll back b1, patch b3, patch b1 again) In practice, it’s impossible to handle that combinatorial explosion, so you get updates that require b1 to b3 to be fixed, that require service pack x, etc. However, the system still is designed to handle that. It sort-of must, given that Microsoft occasionally releases updates that it hasn’t tested on all possible hardware configurations, but that (may) solve a specific problem (https://blogs.technet.microsoft.com/mrsnrub/2009/05/14/gdr-qfe-ldr-wth/ https://blogs.technet.microsoft.com/mrsnrub/2009/05/14/gdr-q... is dated, but, I think, still illustrates the problem)

ocdtrekkie 8y ago

Is it using an SSD? Your graphics card is irrelevant. Most of your processor is irrelevant. If you use Windows 10 on a classic hard drive, you're going to have a bad time.

acdha 8y ago
SSD doesn’t matter much, either. It’s single-thread CPU bound in very inefficient code.
mikhailt 8y ago
I have a Samsung 970 Pro, which is NVMe m.2 SSD. It still took an hour to install the feature update like 1809. I believe someone mentions that feature updates like 1809/1803/etc are not actual patches based on current install, it is a complete OS reinstall, which explains the slow install.
- Joeri 8y ago
  You used to have to reinstall windows every few years because it slowed down over time. I guess microsoft thought it would be convenient if they did that for us.
- Schlaefer 8y ago
  The 1809 update took ten minutes on an average notebook with SSD here. MS did some serious work in the last releases to reduce the offline time for updates. See e.g. https://insider.windows.com/en-us/articles/were-listening-to-you/ https://insider.windows.com/en-us/articles/were-listening-to...
chmln 8y ago
Yes, the laptop always had an SSD and I know about the difference an SSD can make in terms of overall performance. However, the same comparison holds. I have an older backup PC in the basement with a hard drive, and it still takes just a few minutes to update in the background on Linux. Windows on that machine was simply unusable.
PSZD 8y ago

cmurf 8y ago

My vague understanding is there's some kind of inode lock on in-use libraries, and only a reboot releases them. Therefore files can't really be overwritten. New files (and inodes) are written elsewhere, and then moved into place as part of the reboot. Two things I don't understand: why updates are so slow; and why the updating can't be done out of band. Seems like it could be done either with hardlinks or using VSS, so that it's safe to do as a background process rather than effectively kicking the user off their own system for the entire duration. Both hardlinks and VSS have been around forever on NTFS. While ReFS supports volume snapshots (but not hardlinks), its rollout as a replacement for NTFS appears stalled, only being recommended for specific use cases that aren't the general purpose use case (system disk).

rincebrain 8y ago
1) The deleting in-place is just a different default than on e.g. Linux - both can let you delete/rename/etc files underneath it, but Windows defaults to making you explicitly set a property to permit this in your open() call equivalents, while Linux requires you explicitly lock things to prevent this. 2) Updates can be slow for a bunch of reasons. One of them is that the WU agent as shipped in e.g. Win7 SP1 had some nasty O(n^2) or worse operations that got fixed in [1] and later. One of the reasons the monthly rollups versus itemized bits were an enhancement is, if your install for each update is NUMUPDATES* O(start transaction + do install of update bits + swap into place + end transaction) , removing all but one of the start and end transactions is a nice speedup. As far as using hardlinks and VSS to stage and swap updates into place...that is a thing that WU does already, and has done for quite some time. ReFS also makes me sad because it has so much potential, but they rolled it out without being able to used for many use cases, so it's probably gonna stall and die. [1] - https://support.microsoft.com/en-us/help/3161647/windows-update-client-for-windows-7-and-windows-server-2008-r2-june-20 https://support.microsoft.com/en-us/help/3161647/windows-upd...

maskull 8y ago

Yea, a fan in my laptop was failing and I mostly noticed it on Patch Tuesday.

chis 8y ago

This comment is totally unrelated to the article.