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

wish: show search progress on slow searches

Expand Messages
  • Yakov Lerner
    Wish: when search is slow, show the progress line number every second on the bottom line (like, 12345 of 99999). Maybe this can be done with plugin, I m not
    Message 1 of 7 , Apr 4, 2007
    • 0 Attachment
      Wish: when search is slow, show the progress line number
      every second on the bottom line (like, 12345 of 99999).

      Maybe this can be done with plugin, I'm not sure.
      Maybe simply status line can be refreshed once in a second,
      temporarily setting line number to the current search position.

      Some regexes take half minute to several minutes time
      on multimegabyte file. It would be nice to see the progress numbers onscreen.

      Thanks
      Yakov
    • Bram Moolenaar
      ... What is slow? 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
      Message 2 of 7 , Apr 29, 2007
      • 0 Attachment
        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?

        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).

        > Maybe this can be done with plugin, I'm not sure.

        Probably not without a big performance hit.

        > Maybe simply status line can be refreshed once in a second,
        > temporarily setting line number to the current search position.

        That would be confusing. Need to show it somewhere else (but where?).

        > Some regexes take half minute to several minutes time on multimegabyte
        > file. It would be nice to see the progress numbers onscreen.

        True. Some of my functions also echo the current line number now and
        then.

        --
        "You know, it's at times like this when I'm trapped in a Vogon airlock with
        a man from Betelgeuse and about to die of asphyxiation in deep space that I
        really wish I'd listened to what my mother told me when I was young!"
        "Why, what did she tell you?"
        "I don't know, I didn't listen!"
        -- Arthur Dent and Ford Prefect in Douglas Adams'
        "The Hitchhiker's Guide to the Galaxy"

        /// 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
        ... To my taste, when something takes longer than 1-2 sec, I d prefer some visual feedback on the progress. ... Checking for time every several hundred (N)
        Message 3 of 7 , Apr 29, 2007
        • 0 Attachment
          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.

          Yakov
        • Yakov Lerner
          ... 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
          Message 4 of 7 , Apr 30, 2007
          • 0 Attachment
            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.
            >
            > Yakov
            >

            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.

            Yakov
          • 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 5 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 6 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 7 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.