46691Re: wish: show search progress on slow searches
- Apr 30, 2007On 4/30/07, Bram Moolenaar <Bram@...> wrote:
>How about using SIGALRM when search is progressing, every second ?
> [This is development, removed the Vim maillist]
> Yakov Lerner wrote:
> > On 4/29/07, Yakov Lerner <iler.ml@...> wrote:
> > > On 4/29/07, Bram Moolenaar <Bram@...> wrote:
> > > >
> > > > Yakov Lerner wrote:
> > > >
> > > > > Wish: when search is slow, show the progress line number
> > > > > every second on the bottom line (like, 12345 of 99999).
> > > >
> > > > What is slow?
> > > To my taste, when something takes longer than 1-2 sec,
> > > I'd prefer some visual feedback on the progress.
> > >
> > > > Checking if the second passed will make the search even slower.
> > > > Checking time is quite slow on some systems (the check for CTRL-C
> > > > suffers from this).
> > >
> > > Checking for time every several hundred (N) lines will probably not slow
> > > the search perceptibly. N can be configurable, a parameter.
> > > Some value between 10 and 1000 will probaby be reasonable.
> > I think it's possibe to check for time, which searching, not too
> > often and not too seldom, even without user-defined parameter.
> > Adaptive algorithm with two counters will find the right rate or
> > time-checking:
> > - as we start search, we check time every 50 lines
> > (N=50 is initial value of N). We maintain counter M. M is how
> > many times we called time() between the seconds changed.
> > M is checked and reset every second. M is checked as folllows:
> > - If M is too high (M>10), then we adjust N by increasing it.
> > If M is too low(M<10), then we adjust N by decreasing it. Ideally,
> > we want to check time() ~10 times per second. (overhead of 10
> > calls to time() per second cannot he high, right ?)
> > - if search progresses for several seconds, then N quickly converges
> > to the "ideal" value (~10 checks/sec).
> > - we start every search with same value of N (say, 50). If search
> > is slow, then N will quickly converge to the "ideal" value for this regex,
> > the value in which where time() is checked ~10 times per second.
> It will help for differences in speed for various patterns, but it won't
> help for lines differing in length. Quite a few patterns with wildcards
> depend on the line length a lot.
> It might work better to adjust to the delay caused by the time
> function. This varies greatly between systems. When it's fast we can
> check the time often, when it's slow it delays the search more and
> should be called less often.
SIGALRM handler would store time() into global var (and reload alarm(1)).
The search would check the global var for changes, every line.
It is cheap to check global integer (time_t) var, no ?
- << Previous post in topic Next post in topic >>