tags:

views:

2074

answers:

8

What's a good algorithm for determining the remaining time for something to complete? I know how many total lines there are, and how many have completed already, how should I estimate the time remaining?

A: 

That really depends on what is being done... lines are not enough unless each individual line takes the same amount of time.

The best way (if your lines are not similar) would probably be to look at logical sections of the code find out how long each section takes on average, then use those average timings to estimate progress.

chills42
They probably won't take the same amount of time, but I really just want to estimate the remaining time. I know it won't be 100% accurate.
Aaron Smith
+9  A: 

Why not?

(linesProcessed / TimeTaken) (timetaken/linesProcessed) * LinesLeft = TimeLeft

TimeLeft will then be expressed in whatever unit of time timeTaken is.

Edit:

Thanks for the comment you're right this should be:

(TimeTaken / linesProcessed) * linesLeft=timeLeft

so we have

(10/100) * 200 = 20 Seconds now 10 seconds go past
(20/100) * 200 = 40 Seconds left now 10 more seconds and we process 100 more lines
(30/200) * 100 = 15 Seconds and now we all see why the copy file dialog jumps from 3 hours to 30 minutes :-)

JoshBerke
Maybe I'm missing something here. Say we processed 100 lines over 10 seconds, with 200 lines left. That gives us (100/10)*200 = 2000 seconds left. Now 10 seconds pass with no more lines processed. Now, time left is (100/20)*200 = 1000 seconds left even though no more processing has occurred.
17 of 26
I'm not certain this equation is completely correct.
GWLlosa
the expression should be (TimeTaken/linesProcessed)*linesLeft
Pete Kirkham
Yea the expression was wrong;-) But it was right in the spirit of things!
JoshBerke
A: 

If you know the percentage completed, and you can simply assume that the time scales linearly, something like

timeLeft = timeSoFar * (1/Percentage)

might work.

GWLlosa
A: 

there is no standard algorithm i know of, my sugestion would be:

  • Create a variable to save the %
  • Calculate the complexity of the task you wish to track(or an estimative of it)
  • Put increments to the % from time to time as you would see fit given the complexity.

You probably seen programs where the load bar runs much faster in one point than in another. Well that's pretty much because this is how they do it. (though they probably just put increments at regular intervals in the main wrapper)

fmsf
+1  A: 

It depends greatly on what the "something" is. If you can assume that the amount of time to process each line is similar, you can do a simple calculation:

TimePerLine = Elapsed / LinesProcessed
TotalTime = TimePerLine * TotalLines
TimeRemaining = TotalTime - LinesRemaining * TimePerLine
Michael Meadows
+2  A: 

Generally, you know three things at any point in time while processing:

  1. How many units/chunks/items have been processed up to that point in time (A).
  2. How long it has taken to process those items (B).
  3. The number of remaining items (C).

Given those items, the estimate (unless the time to process an item is constant) of the remaining time will be

B * C / A

casperOne
Which time to process can never trully be constant can it? the difference might be negligable especially on small batches, but you can't control the system outside of your own app, plus it wouldn't be constant btw different hardware.
JoshBerke
The issue on hardware changing is irrelevant, as you're the CURRENT run for this equation, and presumably the hardware doesn't change by too much between lines 10 and 11.
GWLlosa
+9  A: 

Make sure to manage perceived performance.

Although all the progress bars took exactly the same amount of time in the test, two characteristics made users think the process was faster, even if it wasn't:

  1. progress bars that moved smoothly towards completion
  2. progress bars that sped up towards the end
Anthony Mastrean
Yeah, I read that post. And I felt the effects of what he was talking about too. Copying felt REALLY slow in Vista, but apparently because of the progress bar and not the actual time it took.
Aaron Smith
No. Copying **is** really slow in Vista. And deleting, and un/sharing...
DisgruntledGoat
I agree Disgruntled. It's much better in Windows 7, much like everything else in Windows 7.
Aaron Smith
A: 

Where time$("ms") represents the current time in milliseconds since 00:00:00.00, and lof represents the total lines to process, and x represents the current line:

if Ln>0 then
    Tn=Tn+time$("ms")-Ln   'grand total of all laps
    Rn=Tn*(lof-x)/x^2      'estimated time remaining in seconds
end if
Ln=time$("ms")             'start lap time (current time)
Alexander V