tags:

views:

243

answers:

4

Pretty much we've all done an installer here and there - and all of us did an installation of some behemoth of a program. Why do some installations take so much time? Case in point: Adobe CS suite (with newer versions you can take a vacation) or Visual Studio.

I know there are files to copy - most of the time unpack even. There are some registry keys to set (if under Windows), maybe a service or couple to start. Some installations probably even check hardware/software combination. All of this does not justify sllloooow installation time in some of the programs.

How can I speed it up?

+4  A: 

Visual Studio on my machine is 3.03GB - 16,842 files in 1,979 folders. Passing 3GB through virus scan and auditing software and onto the filesystem is too much for my (dualcore,2GB,sata2) system - it's CPU or IO bound the whole way through the process. That's why it takes so long.

Colin Pickard
Even more, usually the installers are digitally signed requiring validation, related products have to be searched and updated, dependencies have to be checked etc...
0xA3
good point on digital signatures. I forgot about that.
Keyframe
+2  A: 

Most installers not only pack, but also compress their contents, so at installation time all of these files must be decompressed. All of the data that is decompressed must be written to disk after it is decompressed as well.

Look at the time a zip operation takes on several files. It's also slow.

Brian R. Bondy
+5  A: 

It obviously depends what you're installing As Colin Pickard pointed out, you'll be shifting huge quantities of data onto the disk (+optional virus check etc.).

For installations I've built recently, we have to request the shut down of some Windows services, wait for that, and check that they really have shut down before continuing. That takes time.

I confess that in the above, that's not parallelised, whereas it could be. I suspect that installations are not necessarily optimised. They may well be the last thing that the team put together prior to release, and they may well figure that you're only going to do it once (and forget the pain upon completion). Obviously not an ideal state of affairs!

Brian Agnew
in other words - sloppy job is sloppy I guess.
Keyframe
Well, perhaps. If you have a finite set of resources (team members) and time, then perhaps you should optimise the application rather than the installation. In my case, my customers don't do the install, so they don't care about how efficient the install is, so long as it doesn't restrict rollouts.
Brian Agnew
A: 

Many installers maintain a log that is flushed to the disk after each primitive operation so that even if installation encounters a fatal failure the log is preserved and can be sent to the software vendor. Such flushing sums up and significantly contributes to overall time.

sharptooth