Re: [PATCH 1/5] prune-packed: don't call display_progress() for every file

Nicolas Pitre <nico@cam.org> wrote:

If you go back into the history and look at the commit message for when I introduced this per-object display_progress() call we find the following:

 commit b5d72f0a4cd3cce945ca0d37e4fa0ebbfcdcdb52
 Author: Shawn O. Pearce <spearce@spearce.org>
 Date:   Fri Oct 19 00:08:37 2007 -0400

[...snip...]
    We perform the display_progress() call from within the very innermost
    loop in case we spend more than 1 second within any single object
    directory.  This ensures that a progress_update event from the
    timer will still trigger in a timely fashion and allow the user to
    see the progress meter.

During my testing with a 40,000 loose object case (yea, I fully unpacked a git.git clone I had laying around) my system stalled hard in the first object directory. A *lot* longer than 1 second. So I got no progress meter for a long time, and then a progress meter appeared on the second directory.

The display_progress() call already does a reasonably cheap comparsion to see if the timer has tripped or if the percent complete has changed. So I figured it was more useful to get feedback to the user that we were working, but were going to take a while, than it was to optimize a few machine instructions out of that inner-most per-object loop.

So I'm a little against this patch.  But I think I understand why
you think its worth doing.  I just consider the progress feedback
more important than the few machine cycles avoiding it saves.