For anything but the simplest package you’re not really installing “just” the software, you’re also installing helper libraries from other vendors.
Say your product depends on directx10, and some Visual Basic runtime, These things may well be already installed because many other products also use them, but your installer has to cope with them not being there critically your installer _doesnt know_ ahead of time if they are there.
As a user you see a progress bar that takes massive leaps because before it knew that directx was installed you were only 20% through, and now it turns out it is installed you are 80% of the way there, Visual Basic, also installed and youve jumped to 90% done, just the last 10% to do then. But the last 10% is your code, there is no way that’s already installed so that part always takes 10% of the worse case time.
Progress bars are totally arbitrary and up to whoever is writing the installer. Someone might do it based on % of files transferred, or % of total size transferred, something in between, or something completely unrelated.
That said, you (and I) probably notice the ones that are the least representative of actual behavior and forget about the ones that work as you’d expect, because brains are weird.
For a lot of software, it is in the main phase, unpacking the main data which can often be fewer but larger files, so its fairly steady. Near the end is where generally the smaller more plentiful files get unpacked and organized. The installer also has to clean up a lot of the working data from the install at this last point. Unpacking a large file takes less time per mb than unpacking a lot of smaller files because there is transfer time in between the files. Think of it like unfolding a table cloth with many folds verses a bunch of napkins one by one but with the same surface area.
There are multiple ways to make a progress bar, so depends on the implementation. I suspect, that when it comes to software installation, it is basically a lot of files being unpacked in the back. When it comes to lots of read and write operations, computers behave in a little funny, albiet logical way.
Imagine, you have 1 big video file of 1GB, and then 1,000,000 small files of 1KB each. Will it take the same time to copy both sets, with the same hardware? NO.
For every file, the computer has to
– Find a space on the disk
– Reserve that space
– Read Data
– Write to new space
Now, for that single 1GB file, the first two steps are done only once. While for the 1,000,000 smaller files, the first two steps are done for each file (ie 1 million times). Hence, copying 1 million small files is much slower than copying one big file, even if they are the same size.
When it comes to software installation, the installer might look at the total size of files being written, and give you a progress bar based on it, but the big files may get picked up soon, and get written, while lots of smaller files remain at the end. and hence, even after 99% of the space taken by the files may be filled, there might be thousands of smaller files in that 1%, that are taking a little extra time than one would expect.
Think like you’re carrying a box with lots of toys in it. You need to take it from the living room to your room and place all them in the right spot.
Someone decided 90% of the work just carrying the box, 10% is putting them on place.
But carrying the box is quick, you can do it in a minute. Putting the toys in place takes a lot longer, maybe 4 minutes.
An accurate progress bar is difficult to code and are not critical so many are done as a last minute best effort.
There are examples in the past of progress bars that were designed to go up to a set percentage over a period of time independent of the actual state of loading. Once the time was done, it would stay at that set percentage until everything was loaded. This caused a lot of frustration as computers became faster but these programs refused to start until at least 10 minutes went past.
TLF5YO:
Progress bars are hard to get right but as long as it is moving everything is going to be okay.
The installer has no idea how long it will take (because it depends). The progress bar is mostly arbitrary just, so user know something is happening. It just can’t end before the installation is completed. That’s why it’s most often stuck on 99%. Other option is adding x% after each complete step, but all steps are not equally long.
TLDR.: No one is gonna waste time trying to make accurate progress bar.
Latest Answers