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

Re: wish: show search progress on slow searches

Expand Messages
  • Bram Moolenaar
    [This is development, removed the Vim maillist] ... It will help for differences in speed for various patterns, but it won t help for lines differing in
    Message 1 of 7 , Apr 30, 2007
    • 0 Attachment
      [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.

      - Bram

      --
      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
      ... How about using SIGALRM when search is progressing, every second ? SIGALRM handler would store time() into global var (and reload alarm(1)). The search
      Message 2 of 7 , 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
      • A.J.Mechelynck
        ... [...] ... I don t know about Bram, but how portable is SIGALRM? Can you use it on non-Unix-like systems such as Windows? Wouldn t counting lines be both
        Message 3 of 7 , May 3, 2007
        • 0 Attachment
          Yakov Lerner wrote:
          > On 5/1/07, Yakov Lerner <iler.ml@...> wrote:
          [...]
          >> 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
          >

          I don't know about Bram, but how portable is SIGALRM? Can you use it on
          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.


          Best regards,
          Tony.
          --
          Your lucky number has been disconnected.
        Your message has been successfully submitted and would be delivered to recipients shortly.