Added feedback after each roughly 100,000 file system objects.

[HumanJHawkins]

Added a separate count for tracking when to give feedback. Used this method instead of modulus operator in attempt to stay true to the original intent of this being an extremely fast implementation. Yet needed some indication that the program is not stalled during count of entire drives, etc.

I notice my IDE removed some line ending whitespace, making the default diffing at github difficult. To ignore whitespace changes during review at github, add ?w=1 to the URL. For example:
https://github.com/ChristopherSchultz/fast-file-count/compare/master...HumanJHawkins:master?w=1

Thanks for considering this change.
Jeff

[ChristopherSchultz]

I'm trying to decide if I want to merge this. In general, I like the idea. On the other hand, it's quite arbitrary what that feedback limit is... you want 100,000, others might want 1M, etc. Adding command-line options complicates the program, while recompiling is not terribly convenient.

Given that this is essentially a demonstration program for programmers, I think it would be okay to use a compile-time constant. Can you adjust your PR to #define a constant for the magic-number when feedback is given?

I'm about to commit a few changes to the master, so please make sure you pick those up.

[HumanJHawkins]

Understood. I had a similar concern. More of an aversion to adding anything to what is intended to be an extremely simple and fast demo. But decided to PR this more as an indication that it hasn't hung than as a feedback on quantity.

Will grab any changes and look at adding the #define with minimal additional complexity. A good implementation for the end-user would involve being able to turn it off, and mitigating or warning about potential choices that would slow it down. Like getting feedback after every file. But that would be a poor implementation for the demo-oriented purpose of this program.

So perhaps just a #define, with comments in the code to indicate how to effectively turn it off (setting a really large number) and the problems caused by a really small number (i.e. slowness)?

Hope to revise the PR soon... May not look at it until tonight.

[ChristopherSchultz]

Sounds good. The "slowdown" would only be detectable if the user set the value to something really low, and lots of stdout messages were being dropped. Reading the filesystem is going to be the bottleneck in this program, not incrementing a long value.

[HumanJHawkins]

I believe I've implemented this as suggested. As compared to the earlier code, the following changes have been made:

1. FEEDBACK_INTERVAL is set via #define
2. Simplified the output... Feedback and final result now flow smoothly from one to the other via refreshing/updating a single line.
3. Made default interval 10,000, as this seems a better fit for the simplified output.

Thanks.