21 ms·

Install -> happy -> slows down -> random crashes -> slows down more -> reinstall -> repeat One thing I think happens is Registry gets abused by apps and such o

Install -> happy -> slows down -> random crashes -> slows down more -> reinstall -> repeat One thing I think happens is Registry gets abused by apps and such over the years.

Crinus 7y ago
This is one of those 90s inspired urban tales. Even a decade old CPU can rip through the entire registry without breaking a sweat. And it is just a hierarchical database, nothing special about it. It shouldn't be very different than accessing files on the file system. (there were some bugs at the past that caused Windows Explorer to slow down but those were fixed long ago and they were just bugs with a single application, not something inherently slow with the registry itself)
- pjc50 7y ago
  It's not the registry itself, it's using the word "registry" as a synecdoche for all the things that may be installed there. And hooked into Windows subsystems. Speaking of Explorer, one of the classic ways to end up with a Windows system that's slow for no readily apparent reason is shell extensions. Either on the rightclick menu or in the thumbnail engine. At one point I had a folder I couldn't navigate to without getting an error popup that mentioned Nvidia in it - a chain of handlers had been installed such that JPEG decoding was delegated to the graphics card, so trying to create and cache the thumbnail of a corrupt file crashed in an unrelated-looking place.
  - Crinus 7y ago
    Well yeah, but it isn't specific to registry or even to Windows, you could get that with pretty much any extensible system. In Window Maker, for example, you can set up the application menu to use a dynamically filled entry so i wrote a shell script that scan my Steam folder to fill the installed games. Any mistake there could have had a similar outcome (e.g. launching Steam every time i right clicked on the desktop or generating an endless .\.\.\.\.\.\.\. list from not skipping the . directory or whatever). KDE and GNOME have many extensions and people already complain about GNOME's performance when it comes to shell extensions.
- Jemm 7y ago
  So why does a search of the registry with zregedit take so long?
- rbanffy 7y ago
  It's not that the registry grows large. It's because it accumulates cruft. If your software relies on information in the registry to make decisions, it'll often make decisions based on outdated information a long uninstalled (or upgraded) program left there. It's the wrong solution to an old problem: having your configuration in hundreds of .INI files was a problem because opening and reading files took a long time. Instead of solving the problem and making opening and reading hundreds of files fast (which would be awesome for a number of other uses of a computer) they created new file that every application would read and write to. It seemed like a great idea at the time. Every problem has a solution that's simple, elegant, and wrong.
  - theandrewbailey 7y ago
    > If your software relies on information in the registry to make decisions, it'll often make decisions based on outdated information a long uninstalled (or upgraded) program left there. Why is your software looking at registry entries that it didn't create?
    - rbanffy 7y ago
      > Why is your software looking at registry entries that it didn't create? I may want to know where Photoshop is installed to I can register a plugin. Or know about the printers installed. Or know more about the environment than the OS is willing to tell me. Or those may be entries that older versions of other applications of mine did create. Or Windows. Or older versions of Windows. There are many reasons to look into registry entries that aren't the ones you wrote.
  - WorldMaker 7y ago
    > It's not that the registry grows large. It's because it accumulates cruft. This seems to be the correct answer, but not for the reason you think ("outdated information"). The registry is a highly indexed database, because it needs to be quick at answering if say a low-level kernel-level driver needs something in real time for an operation. Many of those indexes are variations on Most-Recently-Used (MRU) caches. The more applications that make random queries to the Registry, the more those MRU caches churn and the more likely the MRU caches are full of small, one-off application data versus important stuff that needs to be queried as quickly as possible. (Over time Windows has seemed to work to compensate by changing indexing strategies, but at a high level a lot of the slow down issues with registry still boil down to index problems.) The Registry wasn't intended to be a general application configuration store, per the original registry usage guidelines. Certainly that ship sailed. (Also, the key problem with INI files was not that opening/reading them took a long time, it was the same centralization problem: almost every Windows 3.x application stored their INI in C:\WINDOWS for a number of dumb reasons. When Windows 9x started enforcing basic directory ACLs and not every program under the sun could read/write to arbitrary files in C:\WINDOWS, people scurried for the Registry as that seemed the closest to what they were already doing, squirreling config data in C:\WINDOWS for dumb reasons. It took a while for developers to realize they should just put config files in whatever format they prefer in %LOCALAPPDATA% or such like and stop trying to centralize them.)
- jsight 7y ago
  I agree with everything that you said, except the part about windows explorer slowdowns being fixed. I still find it to be an order of magnitude slower than Gnome's file manager for simple cases. I understand some of the reasons why this is, but its still pretty nasty.
- wink 7y ago
  I might have agreed with you up to ~2 months ago (my 2 Win7 installs had been running for 3-4 years each) until a real, normal, official Radeon graphics card update completely hosed the install. Unusable and unrecoverable from the save point thing, whatever it's called. Sure, it happens rarely - but it really depends on your usage patterns. If you often have to try out software on a regular basis (I've always used Windows VMs for work stuff when I needed to evaluate things from $randomVendor) it might accelerate this. Or sometimes it's a piece of hardware. yes, some are 90s tales but to some degrees it has persisted.

Install -> happy -> slows down -> random crashes -> slows down more -> reinstall -> repeat One thing I think happens is Registry gets abused by apps and such over the years.

Crinus 7y ago

This is one of those 90s inspired urban tales. Even a decade old CPU can rip through the entire registry without breaking a sweat. And it is just a hierarchical database, nothing special about it. It shouldn't be very different than accessing files on the file system. (there were some bugs at the past that caused Windows Explorer to slow down but those were fixed long ago and they were just bugs with a single application, not something inherently slow with the registry itself)

pjc50 7y ago
It's not the registry itself, it's using the word "registry" as a synecdoche for all the things that may be installed there. And hooked into Windows subsystems. Speaking of Explorer, one of the classic ways to end up with a Windows system that's slow for no readily apparent reason is shell extensions. Either on the rightclick menu or in the thumbnail engine. At one point I had a folder I couldn't navigate to without getting an error popup that mentioned Nvidia in it - a chain of handlers had been installed such that JPEG decoding was delegated to the graphics card, so trying to create and cache the thumbnail of a corrupt file crashed in an unrelated-looking place.
- Crinus 7y ago
  Well yeah, but it isn't specific to registry or even to Windows, you could get that with pretty much any extensible system. In Window Maker, for example, you can set up the application menu to use a dynamically filled entry so i wrote a shell script that scan my Steam folder to fill the installed games. Any mistake there could have had a similar outcome (e.g. launching Steam every time i right clicked on the desktop or generating an endless .\.\.\.\.\.\.\. list from not skipping the . directory or whatever). KDE and GNOME have many extensions and people already complain about GNOME's performance when it comes to shell extensions.
Jemm 7y ago
So why does a search of the registry with zregedit take so long?
rbanffy 7y ago
It's not that the registry grows large. It's because it accumulates cruft. If your software relies on information in the registry to make decisions, it'll often make decisions based on outdated information a long uninstalled (or upgraded) program left there. It's the wrong solution to an old problem: having your configuration in hundreds of .INI files was a problem because opening and reading files took a long time. Instead of solving the problem and making opening and reading hundreds of files fast (which would be awesome for a number of other uses of a computer) they created new file that every application would read and write to. It seemed like a great idea at the time. Every problem has a solution that's simple, elegant, and wrong.
- theandrewbailey 7y ago
  > If your software relies on information in the registry to make decisions, it'll often make decisions based on outdated information a long uninstalled (or upgraded) program left there. Why is your software looking at registry entries that it didn't create?
  - rbanffy 7y ago
    > Why is your software looking at registry entries that it didn't create? I may want to know where Photoshop is installed to I can register a plugin. Or know about the printers installed. Or know more about the environment than the OS is willing to tell me. Or those may be entries that older versions of other applications of mine did create. Or Windows. Or older versions of Windows. There are many reasons to look into registry entries that aren't the ones you wrote.
- WorldMaker 7y ago
  > It's not that the registry grows large. It's because it accumulates cruft. This seems to be the correct answer, but not for the reason you think ("outdated information"). The registry is a highly indexed database, because it needs to be quick at answering if say a low-level kernel-level driver needs something in real time for an operation. Many of those indexes are variations on Most-Recently-Used (MRU) caches. The more applications that make random queries to the Registry, the more those MRU caches churn and the more likely the MRU caches are full of small, one-off application data versus important stuff that needs to be queried as quickly as possible. (Over time Windows has seemed to work to compensate by changing indexing strategies, but at a high level a lot of the slow down issues with registry still boil down to index problems.) The Registry wasn't intended to be a general application configuration store, per the original registry usage guidelines. Certainly that ship sailed. (Also, the key problem with INI files was not that opening/reading them took a long time, it was the same centralization problem: almost every Windows 3.x application stored their INI in C:\WINDOWS for a number of dumb reasons. When Windows 9x started enforcing basic directory ACLs and not every program under the sun could read/write to arbitrary files in C:\WINDOWS, people scurried for the Registry as that seemed the closest to what they were already doing, squirreling config data in C:\WINDOWS for dumb reasons. It took a while for developers to realize they should just put config files in whatever format they prefer in %LOCALAPPDATA% or such like and stop trying to centralize them.)
jsight 7y ago
I agree with everything that you said, except the part about windows explorer slowdowns being fixed. I still find it to be an order of magnitude slower than Gnome's file manager for simple cases. I understand some of the reasons why this is, but its still pretty nasty.
wink 7y ago
I might have agreed with you up to ~2 months ago (my 2 Win7 installs had been running for 3-4 years each) until a real, normal, official Radeon graphics card update completely hosed the install. Unusable and unrecoverable from the save point thing, whatever it's called. Sure, it happens rarely - but it really depends on your usage patterns. If you often have to try out software on a regular basis (I've always used Windows VMs for work stuff when I needed to evaluate things from $randomVendor) it might accelerate this. Or sometimes it's a piece of hardware. yes, some are 90s tales but to some degrees it has persisted.