Thread: Percentage Complete?

  1. #1
    Registered User
    Join Date
    Sep 2006
    Posts
    230

    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

  2. #2
    The larch
    Join Date
    May 2006
    Posts
    3,573
    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.
    I might be wrong.

    Thank you, anon. You sure know how to recognize different types of trees from quite a long way away.
    Quoted more than 1000 times (I hope).

  3. #3
    Registered User
    Join Date
    Sep 2006
    Posts
    230
    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.

  4. #4
    Sweet
    Join Date
    Aug 2002
    Location
    Tucson, Arizona
    Posts
    1,820
    Seems alright to me.

  5. #5
    and the hat of int overfl Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    39,659
    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.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.

  6. #6
    Registered User
    Join Date
    Oct 2001
    Posts
    2,129
    Quote Originally Posted by Salem View Post
    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.

  7. #7
    Algorithm Dissector iMalc's Avatar
    Join Date
    Dec 2005
    Location
    New Zealand
    Posts
    6,318
    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.
    My homepage
    Advice: Take only as directed - If symptoms persist, please see your debugger

    Linus Torvalds: "But it clearly is the only right way. The fact that everybody else does it some other way only means that they are wrong"

  8. #8
    and the hat of int overfl Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    39,659
    > 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 % complete.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.

  9. #9
    Registered User
    Join Date
    Jun 2005
    Posts
    6,815
    Quote Originally Posted by Salem View Post
    > 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 % 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.

  10. #10
    Registered User
    Join Date
    Sep 2006
    Posts
    230
    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?
    Last edited by Abda92; 09-19-2007 at 06:17 AM.

  11. #11
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by Abda92 View Post
    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
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  12. #12
    Frequently Quite Prolix dwks's Avatar
    Join Date
    Apr 2005
    Location
    Canada
    Posts
    8,057
    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.)
    dwk

    Seek and ye shall find. quaere et invenies.

    "Simplicity does not precede complexity, but follows it." -- Alan Perlis
    "Testing can only prove the presence of bugs, not their absence." -- Edsger Dijkstra
    "The only real mistake is the one from which we learn nothing." -- John Powell


    Other boards: DaniWeb, TPS
    Unofficial Wiki FAQ: cpwiki.sf.net

    My website: http://dwks.theprogrammingsite.com/
    Projects: codeform, xuni, atlantis, nort, etc.

  13. #13
    Algorithm Dissector iMalc's Avatar
    Join Date
    Dec 2005
    Location
    New Zealand
    Posts
    6,318

    Some brainfood:

    Time remaining = time_elapsed_so_far * (total_records - current_record) / current_record;


    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.
    My homepage
    Advice: Take only as directed - If symptoms persist, please see your debugger

    Linus Torvalds: "But it clearly is the only right way. The fact that everybody else does it some other way only means that they are wrong"

  14. #14
    Registered User
    Join Date
    Sep 2006
    Posts
    230
    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?

  15. #15
    Registered User
    Join Date
    Jan 2005
    Posts
    7,366
    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.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. binary tree complete check
    By ichijoji in forum C++ Programming
    Replies: 5
    Last Post: 11-12-2004, 05:48 PM
  2. Percentage
    By skyglin in forum C Programming
    Replies: 7
    Last Post: 06-23-2003, 05:18 PM
  3. Doom Lord engine complete!
    By Leeman_s in forum Game Programming
    Replies: 8
    Last Post: 05-12-2002, 12:44 AM
  4. doom lord engine complete!
    By Leeman_s in forum C++ Programming
    Replies: 4
    Last Post: 04-25-2002, 08:41 PM