Tell me more ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.
up vote 2 down vote favorite

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?

share|improve this question

3 Answers

up vote 7 down vote

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.

share|improve this answer
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 '11 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 '11 at 7:30
Doesn't msiexec also verify each file - i.e. calculate a hash on it? That could also account for CPU time. – ultrasawblade Sep 9 '12 at 12:17
up vote 3 down vote

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.

share|improve this answer
up vote 3 down vote

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.

share|improve this answer
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 '11 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 '11 at 7:25

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.