Loading ...
Sorry, an error occurred while loading the content.

46691Re: wish: show search progress on slow searches

Expand Messages
  • Yakov Lerner
    Apr 30, 2007
    • 0 Attachment
      On 4/30/07, Bram Moolenaar <Bram@...> wrote:
      >
      > [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.

      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 ?

      Yakov
    • Show all 7 messages in this topic