Shell Programming and Scripting

Hi,

Does anybody knows how to estimate the duration of a certain process in UNIX?

I'm using Sun solaris system and I'm trying to extract some information from a binary file, but most of the time, the size of this binary file is quite huge hence it'll be great if I would be able to know and estimate how long does it take to perform the extraction process. So ... I don't have to wait in front of my monitor all day.

For example:
extract file123

Any help or advice would be greatly appreciated. Thanks.

Computer scientist answer: it's impossible; this is isomorphic with the halting problem.

Practitioner's answer: if it took ten minutes to process 1%, you can do the math. Or if it took three hours yesterday and two and a half hours on the day before, that's useful data, too. Ballpark figures anyway. Depends on system load and the phase of the moon.

put time in front of the command, e.g.
time gzip -dc file.tar.gz
then you'll be presented with the time that the respective command has taken for execution.

Hi, thanks a lot for your quick response.

I thought it'll good if there is a script or a way to estimate this particular process in UNIX. Sorry, I'm not very good at math, so please help me a bit on this portion.

For example, if I start the extraction process at 9am and perhaps based on the filesize or other factors, is there a better way to estimate the duration of this extraction process?

Thanks.

Without numbers or access to the program, we can't tell you too much. Do you know how long it takes to do 1kb? How about 2kb? Does it grow linearly with the size of the input, or is the curve different? What about memory footprint? (Google for "big-oh" if this is unfamiliar territory.) The actual math is uninteresting, but of course, once you understand the concepts and have some basic metrics to use for the calculations, it's a quick multiplication or two to get a real-world estimate in minutes or hours.

For example, I'm working on a program which needs to compare each input to all collected previous inputs. As the number of previous inputs grows, the running time will grow by one unit for each run. That's linear growth.

Now, I have a different program which needs to reorder all the inputs it remembers. So when a new input comes in, all the inputs need to be recompared against each other, in order to put them in the new correct order. That one doubles its running time each time a new input comes in, because the number of comparisons required doubles.

The O(n) mumbo-jumbo is just a convenient way to talk about these things, it takes about half an hour to get it at first but it's time well spent.

Hi, thank you for your response. Will try to take a look at the recommended O(n) mumbo-jumbo stuff. Hopefully will be able to extract something useful.

Thanks.