How can we estimate the time needed for program to

问题:

This is not programming language specific.

I just need to understand how can I estimate the time needed for a process to complete ? Such as unzipping file for example or burning a CD ? What are the factors that enhance the accuracy of this calculatio ?

Some examples in any programming language will help of course.

回答1:

Record the actual times taken and relevant factors; estimate future times based the averages of past runs with in similar situations. In most cases it will never be all that accurate, but it's better than nothing I suppose.

As you say, this isn't language specific, but it is very situation specific; the factors that are relevant to burning a disc are probably different to the factors that influence the time to unzip a file.

回答2:

Sometimes you simply cannot estimate the time needed for a process to complete. You can come up with all sorts of schemes to estimate this time, but if you get it wrong you run the risk of displaying a progress bar that runs to the end and sits there. This will only frustrate the user.

In these cases it's best to select one of the many GUI elements you have available to assure the user your app is busy doing work for them.

回答3:

I haven't really done much with time estimates, but i can say what I think should be accounted for.

The time complexity of the algorithm: An O(n*n) algorithm is going to take n times longer than a O(n) algorithm. You will most likely need to know the implementation details of whatever you're estimating. Your program's time estimates are going to be porportional to the clock speed of the computer its running on, the harddrive speed, memory clock speed, internet speed, and in the case of disc burning, disk drive speed. If your user's computer is traveling near the speed of light, you'll have to consider stuff like special relativity, but hopefully that's not the case. Most of these can change rapidly, and others are hard to get an estimate of in the first place. There is really too many factors involved in the actual time a program will take. For example, other programs might slow yours down, and I would think its really hard to take this into account.

Sorry, I can't think of any code examples to go along with this that demonstrate things better. I hope this helps though.

回答4:

Whatever you do, make sure that you don't cheat like Windows Explorer does, by creating an exponentially increasing progress bar that never fills up -- it's much more irritating than a marquee progress bar.

回答5:

If you want some precise, "nice" estimates you can probably do all sorts of elaborate and fancy stuff. I only ever need to do this so that I can decide whether I should go get a snack while my program is running, or whether I should sit there and wait for it. So it's enough for me to get a very rough idea of whether the task will take seconds (wait), minutes (get a snack or coffee), hours (time for lunch!) or days (maybe I should optimize this a bit...).

Most of my time-intensive code tends to be a for loop with many iterations. So I just look at how many iterations there are, how many I've done, and how long it has taken me. There I have a key decision to make, it's either:

1) Time to complete an iteration is not significantly correlated to index of the iteration, in which case t_remaining = (t_elapsed / finished_iterations)*remaining_iterations.

2) The index is related to the time per iteration (imagine sorting an array a by finding the maximum and appending it to an array b, removing that element from a, and repeating- finding the maximum will be quicker and quicker as you go on). In this case I would use (I've never needed to yet) t_remaining = t_last_iteration*remaining_iterations.

I have a quick and dirty Matlab function that I call at the end of my for block with the loop's end condition and the current iteration as parameters. It prints information on what percentage of the loop is done and how much more time it will probably take (using method 1 above):

function Progress(now, final)
% Call at inside a time-intensive for-loop with the current i (or other
% counter) in now and the final bound of the loop in final. This function
% will decide whether the rounded percentage has increased, and if it has,
% print progress information to the console.
%
% This expects loops to start at 1 and go up. Transform your variables
% accordingly if that is not the case - if the first time you call this
% function, the first argument isn't 1, you're in trouble.
%
% The aim of this function is to provide feedback on the progress of the
% loop, while making sure exactly 100 lines are printed, regardless of the
% number of iterations in the loop.

    if now == 1
        tic;
    end

    t_elapsed = toc;

    nowPercent = round(100 * now / final);
    oldPercent = round(100 * (now - 1) / final);

    % Calculation rate = (total iterations so far)/(total time passed so far)
    if nowPercent > oldPercent
            t_remaining = round((t_elapsed / now * (final - now)) / 6) / 10;

            disp([num2str(nowPercent) '% complete, estimated '  ...
                num2str(t_remaining) ' minutes remaining...']);
    end
end

Matlab code is pretty self explanatory, in my opinion. The one slightly less-obvious thing: tic starts a stopwatch, and toc returns the time elapsed since the last tic.

You would use it like so:

n = size(inputs);
for i = 1:n
   do_complicated_calculation(inputs(i));

   Progress(i, n);
end

It has many shortcomings, but they are obvious.