2

I've noticed when installing large pieces of software on Windows (Visual Studio, SQL Server, Office, and things of that nature) the installer tends to hang for large periods of time at or near 100% CPU use with little disk activity. What is it doing during these periods? Why in the world would an installer have large (taking sometimes a quarter or half an hour to run) sections of code that are CPU-bound?

Improve this question

3 Answers 3

Reset to default
6

Decompressing. That is the most common reason for using processing power.

There are a lot of other reasons too depending on what is installed such as compiling or calculating.

Improve this answer
3
  • What he said. While we whine and complain about how programs used to fit on floppy disks, applications keep getting bigger and bigger. To "hide" some of that size (and to make distribution of the internet more feasible), most current packages M$ uses employe rather intensive decompression. Even their office formats going back to 2003 have used some pretty strong compression.
    – music2myear
    May 23, 2011 at 21:40
  • Its rarely decompression, modern CPUs can decompress faster than the disk can read data and write it back (of course depends on the compression algorithm). The wait time for pure decompression is probably <1 min per GB of data. See the answer about MSI packages.
    – Spectre
    May 24, 2011 at 7:30
  • Doesn't msiexec also verify each file - i.e. calculate a hash on it? That could also account for CPU time.
    – LawrenceC
    Sep 9, 2012 at 12:17
3

Part of the installation process is to uncompress information that is in the installer. That is probably the high amount of CPU usage that you are seeing. Occasionally an installer will have to download updates, which could take some time depending on how large and what kind of connection.

Improve this answer
3

All of the applications you mentioned are Microsoft properties, so I imagine that they come in Microsoft Installer (MSI) packages.

MSI installers are notoriously slow. The guy who wrote this rant says

Instead of running a program to simply install and let it be done with, it examines the state of your system, then examines the state of the database that is the program's installer, then does a series of overcomplicated calculations about how to reconcile the two.

I'm not in a position to refute or confirm his assertions but they pretty well match up with my own observations.

Improve this answer
2
  • Interesting. I'd like to know in some more detail how this process works, to satisfy my curiosity, as well as proof (here I consider the word of any recognized expert on Windows internals to be "proof") that the assertions are true. If so I'll accept this answer but I gave +1 either way :)
    – Brennan Vincent
    May 23, 2011 at 21:12
  • This applies mainly to MS products that tightly integrate with windows (VS/SQL/Office as you suggested). Large product suites like that have to check compatibility and dependencies, install services, install runtimes, install patches/service packs, migrate settings from previous installs, plug in to other applications, keep the system state consistent if you cancel the install, and record everything that happens so the product can be uninstalled or upgraded at a later date. Contrast to a PC game installer, which mostly just copies/extracts files and has a pretty static uninstaller.
    – Spectre
    May 24, 2011 at 7:25

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .