On 5/1/07, Yakov Lerner <[EMAIL PROTECTED]> wrote:
On 4/30/07, Bram Moolenaar <[EMAIL PROTECTED]> wrote:
>
> [This is development, removed the Vim maillist]
>
> Yakov Lerner wrote:
>
> > On 4/29/07, Yakov Lerner <[EMAIL PROTECTED]> wrote:
> > > On 4/29/07, Bram Moolenaar <[EMAIL PROTECTED]> 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.
How about using SIGALRM when search is progressing, every second ?
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 ?
What do you think about SIGALRM, Bram ?
Yakov
