Re: simple patch for `etags.el'

[Paul Pogonyshev]

> Paul Pogonyshev <address@hidden> writes:
> > Richard Stallman wrote:
> >> Even better, how about not updating the percentage more than once
> >> per second?
> >
> > This turned out not to be better.  Overhead caused by time
> > fetching and comparisons is not worth the gain.  When
> > percentage is printed whenever it changes, `message' is
> > called at most 101 times and that is cheap.  Note that 101
> > is a constant, while the number of constraint evaluations
> > is practically not limited.
>
> You could do the time check only when you are about to call message,
> ie. a max of 101 times.

No, it is not a max of 101 times.  Consider this:

TIME    PERCENTAGE      SHOWING?        COMMENT
0.00    0%              YES             now delaying till at least 1% and 0.20 
seconds
0.01    0%              NO
0.02    1%              NO              but evaluating time constraint
0.03    1%              NO              --"--
0.04    1%              NO              --"--
...

In other words it is max of 101 times that time constraint
will be evaluated and passed.  Number of evaluations that
yield nil is virtually no limited.

Actually, my patch did just this:

        (when (and (reached-next-percentage)
                   (enough-time-has-passed))

but it is slower than just

        (when (reached-next-percentage)

> > So I suggest not bothering with time.  It is faster, gives
> > much simpler code and, finally, once per second is still to
> > rarely, at least to my tastes.
>
> Probably -- but a default period of 0.2 seconds would be ok.

It is OK, but slower.  I posted two versions of `progress-reporter',
first with additional time constraint, the second without.  You
can try both and see that the second is indeed faster.  On tags
completion I had something like 2.1 sec with time constraint
and 1.5 sec without.  Unpatched code runs for at least 5 seconds
here (not measured, but it seems so).

Paul