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?"

sometimes

[MrDoh!]

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.

It's mathematically impossible.

[PseudoThink]

See http://scribblethink.org/Work/kcsest.pdf [scribblethink.org] and http://scribblethink.org/Work/Softestim/softestim.html [scribblethink.org]

(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.)

Cost Benefit

[infernalC]

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.

Re:Can't Go Backwards

[citizenr]

This is why you put two progress bars. One general and one for sub processes.
http://www.codeproject.com/KB/progress/SplitProgressBar/SplitProgressBar.gif [codeproject.com]

Re:sometimes

[PlusFiveTroll]

The Windows8/Server 2012 dialog is much better in this case.

http://encosia.com/blog/wp-content/uploads/2012/09/windows-8-file-copy-dialog.png [encosia.com]

It draws a graph showing you the current rate, in which you can see the average over time.

Re:Crappy software

[Jiro]

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.

Re:Because it should be a graph.

[Anonymous Coward]

Windows 8 actually has this.

Screenshot: http://stackoverflow.com/questions/14064017/is-there-an-api-for-the-windows-8-progress-dialog-api

Re:Because it should be a graph.

[gargleblast]

Holy crap, there it is: http://developers.slashdot.org/comments.pl?sid=3456137&cid=42879657 [slashdot.org]. Thank you, PlusFiveTroll!!! Thank you Windows 8!!!

Re: Can't Go Backwards

[Yaur]

Yes. You aren't doing the IO on the UI thread and posting a message to update the UI, even once per second, will slow down the transfer by an insignificant amount of time and improve the UX dramatically.