# Percentage Complete?

Show 80 post(s) from this thread on one page
Page 1 of 2 12 Last
• 09-18-2007
Abda92
Percentage Complete?
Hi. I have a program that reads a file, modifies the data, then writes it back into another file. I wanted to add a little feature which is the percentage complete. I have a basic view of how to do it, but I'm sure there's a better way.
This is the way I thought of:
-initialize the variable as 0.
-output it as the percentage.
-check size of writing file and divide by size reading file multiplied by 100.
-output '\b' twice and output new percentage.

I have a little problem here though: I don't know how to find the size of a file.

And I'm pretty sure there's a better algorithm out there for this purpose.

Thanks
• 09-18-2007
anon
One way would be to seek to the end of the file when you open it and tell the position. Then seek back to the beginning to start inputting.
• 09-18-2007
Abda92
OK thanks anon that's not a bad way to find the size. But is there any better algorithm? I don't know I feel mine is very cheap if you know what I mean.
• 09-18-2007
prog-bman
Seems alright to me.
• 09-18-2007
Salem
Why not get the size of the file being read (just once), then count how many bytes you've read from the file as you go.
Convert that into a percentage.
• 09-19-2007
robwhit
Quote:

Originally Posted by Salem
Why not get the size of the file being read (just once), then count how many bytes you've read from the file as you go.
Convert that into a percentage.

AFAIK, this would only work reliably when the file is opened in binary mode, not text mode, because of newline translation. not that it would matter that much in this application though.
• 09-19-2007
iMalc
Percentage complete is easy enough, and you seem to know the formula (100 * current / total).
As an exersize, you could try and calculate the estimated time remaining too. I find such things even more useful. See if you can work that one out. Think of specific examples like 1/3 or 2/3 of the way through.
• 09-19-2007
Salem
> AFAIK, this would only work reliably when the file is opened in binary mode, not text mode
True, but since the result is going to be mapped to a range from 0 to 100, I don't think a minor difference in the apparent file size will overly impact the accuracy of the &#37; complete.
• 09-19-2007
grumpy
Quote:

Originally Posted by Salem
> AFAIK, this would only work reliably when the file is opened in binary mode, not text mode
True, but since the result is going to be mapped to a range from 0 to 100, I don't think a minor difference in the apparent file size will overly impact the accuracy of the &#37; complete.

Indeed. The user won't usually care that much if the status report a fraction of a percent out. Only thing to remember, if there is that slight error due to text vs binary mode, is to set the percentage to 100 when the reading hits end of file .... users will tend to worry (and, worse, submit bug reports) if the program starts doing something else when the file reading/processing is reported as only 99% complete.
• 09-19-2007
Abda92
OK it looks like percentage complete is pretty easy. About estimated time, I can't really find a way.

I know I have to divide the remaining size by the rate. But I'll need to know how fast the processor is.

Actually! there's a way to find the speed. You can record how long it takes to write 1 byte. but then again how can I do that while I'm reading and writing files?
• 09-19-2007
matsp
Quote:

Originally Posted by Abda92
OK it looks like percentage complete is pretty easy. About estimated time, I can't really find a way.

I know I have to divide the remaining size by the rate. But I'll need to know how fast the processor is.

Actually! there's a way to find the speed. You can record how long it takes to write 1 byte. but then again how can I do that while I'm reading and writing files?

Well, you probably don't want to update the "percentage done" for every byte you write (unless writing a single byte is REALLY slow).

If you start by taking a "start time", then take the time whenever you find it's time to update the completion percentage (e.g. when you've done another few kilobytes, or 10%, or whatever), you calculate how much time you've spent and calculate the time it should take to complete if you continue at the going rate.

--
Mats
• 09-19-2007
dwks
Most of the time, file I/O is buffered in chunks. So timing one byte wouldn't work very well anyway -- the first byte would take a lot longer than the succeeding bytes. Not to mention that some operating systems have read-ahead, which I think means that they can anticipate which bytes you're going to read next, resulting in even larger buffers.

I think that the buffer size might be contained in BUFSIZ from <cstdio>. I'm not sure if this applies to C++ streams, though it probably does. You might want to use BUFSIZ as your "few kilobytes" value. It ranges from a minimum of 512 upwards. (On my 64-bit Linux system it's 8192.)
• 09-19-2007
iMalc
Some brainfood:
Time remaining = time_elapsed_so_far * (total_records - current_record) / current_record;
:cool:

Of course it wont be accurate until a few records have been processed.
Anyway, I know it's not what you set out to do, so it's just extra related info in case you like to experiment and play around with stuff.
• 09-21-2007
Abda92
OK I integrated the percentage complete successfully. It works perfectly now.

One little issue though: After adding this feature I felt the process of reading and writing is slower. Can a little calculation and output statement make that much of a difference?
• 09-21-2007
Daved
It's possible but not that likely if you do a lot of calculations each time you read a small amount of data. A more likely scenario is if you changed the way you read in the file. For example, if you read and wrote the file in chunks before, but are doing it byte by byte now to keep the progress bar updated, then that will likely slow things down.

I would build the code before and after the changes, then run them one after the other a few times while timing the process to see if there really is a difference. If there is, then you can figure out what went wrong.
Show 80 post(s) from this thread on one page
Page 1 of 2 12 Last