Displaying Progress.

Hi all.

I wrote a relatively big program that scans specified directories and it will print the files found depending on the options entered.

The program works extremely nice. But now I want to add progress percentage displaying. The big problem that I have is that the dir() function (the one that scans the directories and prints the results) is recursive. So, I believe that I should make the function for the progress separately, and call the progress() function every time the dir() function, for example, scans a file. Every time it scans a file, then the progress function will calculate the current progress, make a carriage return and print to screen. The only code I have for that function so far is this:

Code:

---

void progress(bool start) {
        if(start) {
        // first call, get total bytes to be scanned
       
        } else {
        // print out progress
        }
       
        return;
}

---

Suddenly I thought, that to calculate the percentage, I first need to know the total files (or bytes) that are going to be scanned BEFORE I start scanning, so that I could calculate the percentage with the difference of the bytes scanned and the total bytes to be scanned. But scanning for the total size first would take a lot of time! How could I do this better and faster? Can somebody help?

Thanks a lot.

Have you ever wondered why the progress bars in so many software apps seem totally useless? Like, they quickly scroll up to 99% and then hang for ten minutes? Or jump back and forth, seemingly at random?

THIS is why.

Progress bars are evil.

The only thing progress bars are good for in these situations is to let the user know that stuff is going on and to keep waiting. Perhaps instead of "progress" you could just write anything out to the screen just to let the user know that stuff is going on and the program isn't frozen. Also, displaying what is being done can be useful also ("Scanning currentDirectory")

Other than that a true progress bar would be pretty useless unless you coudl define what was going to happen (Just my 2 cents anyway :) )

hmm... Nice observations.

Well then, I think that instead, I could do something like "bytes and files scanned" instead, and just show the user without having to calculate percentage or tell the user an approximate of time that it is going to be done.

Nice idea. I'll skip the progress bar for now.

Thanks, If I get stuck on the way I'll post here.

But... there is one thing you could do.
First scan all root directories (and count them). Say there's 10 directories. Now you know that after each of these directories are complete, you'll have completed 10%. So now you enumerate the directories in the first root directory. Say there's 10 directories here too. Now we know that after completing one of these, we'd have worked out 1% (since this entire directory is worth 10% and there's 10 directories).
It's a bit tricky, and it might slow it down a little, but it works.

Quote:

---

Originally Posted by Elysia

But... there is one thing you could do.
First scan all root directories (and count them). Say there's 10 directories. Now you know that after each of these directories are complete, you'll have completed 10%. So now you enumerate the directories in the first root directory. Say there's 10 directories here too. Now we know that after completing one of these, we'd have worked out 1% (since this entire directory is worth 10% and there's 10 directories).
It's a bit tricky, and it might slow it down a little, but it works.

---

Hmmm.... But what if one of those directories has 250,000 files, and the other one has 2. Both of them will still only count 1% right?

Quote:

---

Originally Posted by samus250

Hmmm.... But what if one of those directories has 250,000 files, and the other one has 2. Both of them will still only count 1% right?

---

Yes. And it's that sort of "logic" which leads to insane progress bars which progress in fits and starts, and why they are a bad user interface idea in the first place. Unless you demonstrably have a meaningful way to cause the progress bar to move smoothly, it is not serving its purpose, which is to indicate to the user in some sense how much time is left in the operation.

Quote:

---

Originally Posted by samus250

Hmmm.... But what if one of those directories has 250,000 files, and the other one has 2. Both of them will still only count 1% right?

---

Yes. It isn't a perfect method, but it's the best one available if you don't want to count all the files/directories beforehand.
You still need to enumerate all directories so you can recurse them, so...

I think the most useful implementations of progress bars are either when there is a defined amount of work that you can set intervals between, or if you have some sort of threaded process that you can update the progress bar with as you learn more about the process.

In the end I think a progress bar is meant to give users some gauge as to how long the process will take, even thoguht it may be wildly inaccurate. In some cases this is ok, but in this case where you are looking at a possible empty folder vs a folder with 10GB worth of files in it, it wouldn't be very helpful :)

Well, it would still tell you how much of the operation has finished, however long time on folder may take.
It's up to the implementer, really. I prefer to see some Visual Feedback than just "Please wait." You'd it's stuck. A progress bar or a counter on how many files/directories that has been counted so far would be good.

Well, I made the "Files Scanned: Bytes Scanned:" thing (which is enough for now), and it seems that the smoothest way through with a progress bar is counting the total files, and then scan them, calculating percentage as it does. Because, it doesn't matter how big the file is, it will always scan at the same speed, because my program only uses the name of the file, it doesn't have to read it completely.

I'll try that later on. But also... I think that counting all the files before wouldn't be that bad. I noticed that all the folder info is stored into RAM. If I scan My Documents folder right after powering on my computer, it will scan very slowly (hard drive making a lot of racket), and the second time, it scans extremely fast (processor fan making a lot of racket). But maybe it wouldn't be as fast in computers with less RAM than mine (4GB).

Thanks.

Quote:

---

Originally Posted by Elysia

Well, it would still tell you how much of the operation has finished, however long time on folder may take.
It's up to the implementer, really. I prefer to see some Visual Feedback than just "Please wait." You'd it's stuck. A progress bar or a counter on how many files/directories that has been counted so far would be good.

---

I agree that something visual is much better. Also, if you can predict and ending point with any amount of accuracy a progress bar is nice. That, however, is the problem with some implementations, you MUST have an ending point for the progress bar.

As I said thoguh, I do like something "moving" to show that it's working and not stuck

Code:

---

char progress[4] = {'\\', '|', '/', '--'};

---

:D

Quote:

---

Originally Posted by samus250

I'll try that later on. But also... I think that counting all the files before wouldn't be that bad. I noticed that all the folder info is stored into RAM. If I scan My Documents folder right after powering on my computer, it will scan very slowly (hard drive making a lot of racket), and the second time, it scans extremely fast (processor fan making a lot of racket). But maybe it wouldn't be as fast in computers with less RAM than mine (4GB).

---

It's HD activity, so it has nothing to do with ram. And since you scan twice, it will add extra overhead.

yeah but... why when I scan it second, it doesn't do any HD activity at all? It's like all the info is already pre-loaded on memory or something.

An operating system could cache a lot of that information so it will go faster the second time, but it's still slower than doing one pass.

yeah well, I think I'll leave it how I have it now, Or maybe try the moving thingy :-)