Slashdot Mirror
Ask Slashdot: Why Is It So Hard To Make An Accurate Progress Bar?
hyperorbiter writes "How come after 25 years in the tech industry, someone hasn't worked out how to make accurate progress bars? This migration I'm doing has sat on 'less than a minute' for over 30 minutes. I'm not an engineer; is it really that hard?"
Comment loading ...
Yes it is "that hard".
I did it all for the penguins!
Yes it is. And to be fair, it's a lot more accurate than Nostradamus ever was.
Things are asyncronous. You wait for things from disk, ram, user input, over the network etc. How long it will take is non-deterministic. So a task composed of a bunch of these little pieces will be non-deterministic too.
One reason is the progress bar starts out as just a generic tool to show that your loading hasn't froze. At first it is parsed correctly with the elements to be loaded, but as scope increases and more things load, it can get sketchy later on.
Another reason is it is difficult to estimate time left. If you look at some old FTP programs, they'd estimate the rest of the download's time based on how fast the previous has taken. Future lag, fragmented files, etc aren't taken into consideration.
There's a bunch more reasons, but namely the progress bar's main purpose is to show you that the whole system isn't locked up, which they've been doing well for the past 30 years or so.
God spoke to me
Copying files. Sure, get a list of the files to be moved, get the size, as files go across, start the % progress meter. What if the network starts slowing down as you start to copy? New files are added. You used a rough calc to get a vague idea as it was 10x faster, but when you start copying, there's a lot of files bigger than you thought. Network's fast, but the end machine you're copying too is having problems keeping up. You start hitting cache, it was fast (and skewed the result) till then, now it's crawling. Installations. All the fun of copying files, but you're updating existing files too, file system may be fragmented, some of the .ini files as you get to may need extra work. Drivers to install may take longer than expected. Once installed, you have to generate/compile/download extra, that's more rough guesses.
As long as the hourglass/cursor/spinner is spinning, and the %'s is going up now and then, probably the best you can ask for. The trend for guesstimating time remaining seems to be diminishing, as surely the main thing most people want is to know 'is this still working or has it hung?' for anything else, logcat/catch stderr'more details' to find out what it's actually doing.
It COULD be more accurate perhaps, but you'd spend so long working it all out in advance, for 9/10 things, it'd have been quicker to just do it.
Waiting for an amusing sig.
It's very hard to predict how long something will take, particularly in relation to other things, if what you're writing is going to be on any number of platforms with different processors, storage, memory and network situations.
You can be reasonably accurate with it, far more than my favorite 99% in 1 second, the last 1% in one hour scenario. There are cleverer and cleverer ways of making it ever more precise, but those methods usually involve spending time on getting it right, and not many people do it.
There's probably a pantent for a "method or apparatus for an accurate display of progress", nobody wants to mess with that (but seriously most of my innacurate progress bars deal with unpredictable things like I/O, or non-uniform sets like loading textures and meshes and animations all together, so who knows how much time it will actually take to process the same ammount of data?)
--
Stay tuned for some shock and awe coming right up after this messages!
You know someone is going to take your suggestion literally as a tutorial on how to implement a progress bar - later they'll come back with some mystical crash always happening at 0%.
Patience is a virtue, but haste is my life.
See http://scribblethink.org/Work/kcsest.pdf and http://scribblethink.org/Work/Softestim/softestim.html
(No, I'm not being serious. The topic just reminded me of when I once jokingly justified a poorly estimated ETA on a "simple" development project by referencing the above paper.)
My favorite terrible progress bar was Internet Explorer, back in its early days of essentially being a renamed version of NCSA Mosaic. When attempting to load a site that wasn't available, the progress bar would slowly creep towards complete, despite the server being completely unresponsive. Then after a long while the browser would give up and stop the progress bar. Why on earth would the progress bar move if the server is completely unresponsive? Who programmed this? I would hope that they, like the inventor of Clippy, suffered a terrible death by fire.
Consider this: Once you've put progress on a bar, you can't take it off. Suppose you start a process that should take 20 minutes, and do the first 5 minutes, progress is now at 25%. But then, partway through, something unexpected happens and you realize the process is actually going to take 40 minutes. You can't take the progress "back" now, that would disorient the user. So you have to rescale the remainder of the bar.
Progress bars do not make sequences of actions complete any faster. In fact, they make them slower.
That being said, take for example an installer that must perform the following steps during an upgrade:
0. Figure out how many files need to be replaced.
1. Replace 30 files of varying sizes.
2. Add 10 files.
3. Update a half million rows inn a table with a million rows setting a column to a computed value based on some predicates.
4. Run a third party installation mechanism (MSM?) for a supporting library, etc.
Modern computers are time-sharing systems. Each process that involves computation is at the mercy of the scheduler in the kernel to give it the cycles it needs to complete. That means that even if you measure the time it takes to complete some process, it's not going to be the same a second time, because the installation process doesn't get undivided attention.
Steps 0 - 2 - you're at the mercy of the IO buses, hard disk, antivirus software interfering, etc.
Step 3 - What shape are the database statistics in? How efficiently can you apply the predicates? What does the distribution of the data look like? You can't tell this ahead of time...
Step 4 - Does this third party installer provide you some sort of metrics as it runs?
These are the sorts of problems to be overcome to do an accurate progress bar. In short, they aren't worth overcoming.
For over 50 years rocket launch countdowns have not run in a linear fashion, sometimes even being set backwards.
You can work out where you are (% completed) or how fast you are going (rate at which the progress bar is growing), but not both at the same time.
It's simple quantum mechanics.
I am anarch of all I survey.
The progress bar on the HTTP download doesn't show the amount of remaining time in the bar. It shows the number of bytes remaining in the bar; the number of bytes remaining can't go into reverse. The time remaining is showed as a numeric value for how long it would take assuming the speed is the same as the speed so far; if the transfer suddenly slows down, this value can go into reverse.
It is hard to make an accurate progress bar because it shouldn't be a bar at all - it should be a graph.
Consider the humble download: bytewise, it might be 97 percent complete, but at the last moment, the bps rate has fallen. With a progress bar indicating a percentage and an estimated time, it might say 97% complete, 3 seconds to go. If the progress indicator was a graph, you could tell that the bps rate has fallen, and that the 3 seconds to go estimate (probably based on a linear extrapolation of progress to date) does not apply.
I have never seen it done though. Partly, because I have never done it.
... when we solve the halting problem. I'm not entirely joking. The main problem with progress bars is that, quite often, it is not possible to accurately estimate how much time is needed to complete a problem (i.e. for the program to halt).
Loban Amaan Rahman ==> Anagram of ==> Aha! An Abnormal Man!
The public opinion of the Progress Bar would be considerably more favorable if programmers would simply treat 100% as if it were 75%.
In other words, do all the stuff you have to do, measuring progress and whatnot, but when you're actually at 80%, report yourself at 60%. Likewise, when you're at 95%, say you're at 70%.
Then, only when you really are completely finished, you jump from 75% to 100% in under a second.
Complaints gone.
-David
You know what I'd like to see more than a working progress bar? A "Cancel" button that actually stops the f*%! process! .
I don't want to finish the sub-process I'm currently doing (which has probably stalled)... just FREAKING STOP.
If you (programmer) want to close connections, or save the changes to the disk, do it in the background. Making me sit there for another 10 minutes while you're "cancelling..." is not helpful. I will force close your program. Failing that I will hard-reset the computer. Seriously.
Unlike porn, which yada yada rimshot hey-ooh!
Give this man some upward moderation.
The problem is that the question is wrong. It's trivial to make a progress bar...just sum up all the things you have to do, and move the bar each time a "thing" is done, rounding to the nearest pixel. It doesn't matter if the "thing" is a byte to copy, a file to install, or any generic task. As long as you can add one to a counter each time you have done another "thing", you can then display it graphically.
The actual complaint is about displaying accurate time remaining to complete the task, which really has nothing to do with the display of the progress bar. Instead, it involves guessing about how long each remaining "thing" will take to complete, and then displaying that sum of those times. This is hard because no matter how accurate the data used to make the guess, something outside the control of the program can disrupt the processing.
I like the new windows 8 transfer bar that shows instantaneous transfer rates (not average) as it progresses left to right. This gives you a very accurate idea of when the transfer will finish, as it can slow down or speed up based on either network congestion or file size (a bunch of small files transfer slower than few big files.)
Careful with names containing L slashdot.org/~AiphaWolf_HK slashdot.org/~AlphaWoif_HK slashdot.org/~AiphaWoif_HK
No, wait. It seems to have stalled.
Have gnu, will travel.
"How come after 25 years in the tech industry, someone hasn't worked out how to make accurate progress bars? This migration I'm doing has sat on 'less than a minute' for over 30 minutes. I'm not an engineer; is it really that hard?"
Yes, because all progress bars are inherently a prediction of things that will happen in the future. If there is any error condition, unusually large blob of data or weirdly structured hard drive to read from, varying bandwidth bottleneck, fritzy peripheral not responding as expected, etc., etc. times a million, then the unusual event will make the prior prediction incorrect and look silly in retrospect. As long as there is any "if-then" clause or error handling in the branches in the system, then the unexpected can happen and make the prediction (progress bar) invalid.
It's analogous to weather prediction. It can't be perfect, it's an extrapolation, but people will always complain about it.
We know where leadership by an anti-intellectual "strongman" who scapegoats minorities and likes boisterous rallies goes
Show progress of the work, not the time. You never know what other things the machine is doing, and is better to give no estimate than a bad one.
And don't suffice with a bar, also provide information on what the process is doing.
-- The Internet is a too slow way of doing things, you'd never do without it.
This problem was solved a long time ago... I still wonder why people don't know how to code a proper progress bar...
HOWTO:
I've left out the easy stuff but this provides for a 99% correct est. Please note that the computer must be from 1 year in the future for this to exceed 87% correctness without causing time dilation within progress meter by blocks remaining^66 msecs. Check Mfg date at start and adjust time est accordingly.
The above is copy-written and my not be used....
Except even the number of tasks is often variable over the life of the task.
Take for example loading a web page. It starts out as 1 task: Get a page from the server. Once you've done that, how many more requests will that first request generate? Impossible to tell. It could be none. It could be hundreds, and some of those can generate their own requests. (etc, etc.)
The answer is this: Some feedback, no matter how incorrect, is better than no feedback at all.
Progress should be reported to the user in outline format. Give the user the list of tasks that the computer is working on, show progress in each task. This is much more informative, and as a user - i'd feel more intimate with the process and in turn more trusting. also this might allow me to troubleshoot things that are moving slowly. some games are great at this, i've never seen it in an OS though.