Why do software installation or updates always go very fast up to 90% complete, then the last 5-10% takes so much longer?
In: Technology
Let’s say I’m a programmer and I have to make a progress bar for shopping for groceries.
Here are the steps:
1. Go to garage
2. Drive to store
3. Get out of car
4. Walk into store
5. Get shopping cart
6. Procure items
7. Pay for items at checkout
8. Return to car
9. Unload groceries
10. Drive home
Since there are 10 steps, I code my progress bar to increase by 10% after each step. I could have been smarter about it, but there’s a lot more on my sprint backlog so this is good enough for now.
Result: progress bar jumps to 10%, waits there the entire time I drive to the store, quickly reaches 50% for a while while I shop, then 60% for a few minutes while I’m in line, then quickly reaches 90% and stays there until I finally get home.
Your progress bar probably works a lot like this. Now, I could program it so the longest steps get more % but a lot of the time that’s hard to predict.
The real key here is that a programmer actually had to decide how to code it up. Some engineer somewhere wrote the code that includes a formula (so to speak) on how to compute the current % and that formula may not be accurate.
When you write to a file typically the operating system will keep the data in memory, so not actually written yet to disk – until it really needs to, which usually happens with an explicit fsync() call at the end of the install that guarantees that the data has actually been written to disk.
Operating systems do this because it’s more efficient to batch the writes and write them as chunks instead of actually going all the way to writing to disk on every write
Rarely are computer tasks able to be divided into uniform parts with each requiring the same amount of time to complete. Instead the overall task is composed of a host of unique functions, much like a zoo is composed of animals of varying sizes and types that need to be feed. Sure I know that the elephants take longer to feed hay than the birds need bird seed, but there are hundreds of birds and only a couple of elephants. And the cats need their food thawed and divided and carefully served to avoid being eaten. On top of that the monkey’s sometimes throw the food back or try to steal some more. So a zoo keeper knows most of these problems, but inevitably its the little stuff that are forgotten that takes 80% of the time. Nursing animals and sick animals, missing food, spoiled food, etc…. The Devil is in the details. So programmers can plan on the big stuff, but we typically underestimate the amount of time that all of the details take.
And every computer is like a different zoo, some with more monkeys and some with pre-thawed meat, …. So its hard to estimate.
90%: purchasing and ordering new carpet, getting it delivered and actually laying it on the floor.
10%: Moving all the damn furniture, finding a place to put the fishtank, getting the sofa into the laundry, unwiring all the connections to the TV, router, computers etc, ungluing the patch in the hallway where it was cemented down, replacing the section of tack-track that broke….
You invite people over to a party and you want to bring out the cake when everyone arrives. People keep asking you when’s cake. If you give a time estimate based on when you think people will fully arrive you will be way off. If you go by when the party starts you would be “stuck at 100%” for a while, or end up in over 100% time. So you just count who is there vs who all RSVP’d. 80% of the people show up before the party start but people trickle in.
A more concrete answer, progress bars can’t tell the future. In some cases you can go off of average run times if it’s on the same system. But usually for something like an installer, there’s multiple steps. Some will move for things like downloads, but you might have a step at the end that takes longer like compiling or coping files.
Basically it’s not a % of the amount of time left, but the amount of work, even if that work might go slower.
Because software developers don’t think like normal people. To you, me and most end users the 100% progress bar means how much time do I need to waste before I can get on with my life.
To the programmer it’s a task list where each task may take 30 or 300 seconds. Nobody knows. It can take 5 minutes to get to 97% but the remaining 3% will take 15.
Loading bars are super inconsistent. There are too many variables to accurately predict the speed unless artificially slowed.
When the software is written they try to do it but always get it incorrect. That is why it is usually super choppy
My guess for the quick last bit is it is closing up everything which doesn’t take long
Because the lazy programmer bases their percentages on number of files, prioritizing larger files first. The smaller files take longer due to indexing so it slows down.
Maybe a dowwnload then installation thing…?
The core of the answer has been given above:
– inability to calculate how long it will really take on your Core 2 Duo
– best-guess implantation based on the creator’s own platform
But I’d also like to add that 99% of the time, the final part of the setup requires cleaning up files and verification of a complete install. That requires a bunch of io, opening/closing file handles, deleting numerous small files, etc.
Latest Answers