Re: wish: show search progress on slow searches
- [This is development, removed the Vim maillist]
Yakov Lerner wrote:
> On 4/29/07, Yakov Lerner <iler.ml@...> wrote:It will help for differences in speed for various patterns, but it won't
> > 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
> - 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.
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.
hundred-and-one symptoms of being an internet addict:
33. You name your children Eudora, Mozilla and Dotcom.
/// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ download, build and distribute -- http://www.A-A-P.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
- Yakov Lerner wrote:
> On 5/1/07, Yakov Lerner <iler.ml@...> wrote:[...]
>> How about using SIGALRM when search is progressing, every second ?I don't know about Bram, but how portable is SIGALRM? Can you use it on
>> 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 ?
non-Unix-like systems such as Windows?
Wouldn't counting lines be both simpler and more portable? You could either
display ...nnn lines scanned... every (e.g.) 100 lines or so, or else
determine during startup how long it takes to get the time (maybe as an
average of 5 tries if you want less stochastic variability) then check the
time it every n lines, with n being a monotonous non-decreasing function of
the time delay thus obtained.
Lines of wildly varying length would make the display change at variable time
intervals (in the second case, if the lines are long enough to require more
than, say, one second between successive checks of the clock), but that
shouldn't be a very serious problem.
Your lucky number has been disconnected.