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

Significant network latency during keyword completion

Expand Messages
  • parcs
    Hi, I noticed that in sessions with many (100+) small buffers, keyword completion over a slow network causes a 2+ second hiccup. I think this is because
    Message 1 of 4 , Jan 14 9:23 AM
      Hi,

      I noticed that in sessions with many (100+) small buffers, keyword completion over a slow network causes a 2+ second hiccup. I think this is because during keyword completion, Vim prints the line "Scanning %s" for each open buffer into the command line. When buffers are small (and therefore keyword scanning is very fast), these screen updates happen very quickly one after another and create a spike in network traffic which causes the underlying SSH session to be unresponsive until all screen updates are accounted for.

      I wonder if instead of printing "Scanning %s" for each buffer in the session during keyword completion, Vim could instead print say "Scanning buffers." just once. This would reduce the amount of screen updates performed during keyword completion, thereby making keyword completion more responsive under slow terminals/networks.

      Here's a candidate patch that implements the above suggestion.

      diff -r 53bfbc9e797d src/edit.c
      --- a/src/edit.c Tue Jan 14 16:55:01 2014 +0100
      +++ b/src/edit.c Tue Jan 14 12:21:31 2014 -0500
      @@ -4180,6 +4180,7 @@
      char_u *dict = NULL;
      int dict_f = 0;
      compl_T *old_match;
      + int began_scanning_buffers = FALSE;

      if (!compl_started)
      {
      @@ -4239,13 +4240,12 @@
      dict = ins_buf->b_fname;
      dict_f = DICT_EXACT;
      }
      - vim_snprintf((char *)IObuff, IOSIZE, _("Scanning: %s"),
      - ins_buf->b_fname == NULL
      - ? buf_spname(ins_buf)
      - : ins_buf->b_sfname == NULL
      - ? ins_buf->b_fname
      - : ins_buf->b_sfname);
      - (void)msg_trunc_attr(IObuff, TRUE, hl_attr(HLF_R));
      + if (!began_scanning_buffers)
      + {
      + vim_snprintf((char *)IObuff, IOSIZE, _("Scanning buffers."));
      + (void)msg_trunc_attr(IObuff, TRUE, hl_attr(HLF_R));
      + began_scanning_buffers = TRUE;
      + }
      }
      else if (*e_cpt == NUL)
      break;

      --
      --
      You received this message from the "vim_dev" maillist.
      Do not top-post! Type your reply below the text you are replying to.
      For more information, visit http://www.vim.org/maillist.php

      ---
      You received this message because you are subscribed to the Google Groups "vim_dev" group.
      To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
      For more options, visit https://groups.google.com/groups/opt_out.
    • Ben Fritz
      ... But with that method, whether on a local PC or over SSH, if there are a lot of LARGE buffers so that scanning for keywords takes a long time, the user will
      Message 2 of 4 , Jan 14 10:49 AM
        On Tuesday, January 14, 2014 11:23:53 AM UTC-6, parcs wrote:
        > I wonder if instead of printing "Scanning %s" for each buffer in the session during keyword completion, Vim could instead print say "Scanning buffers." just once. This would reduce the amount of screen updates performed during keyword completion, thereby making keyword completion more responsive under slow terminals/networks.
        >

        But with that method, whether on a local PC or over SSH, if there are a lot of LARGE buffers so that scanning for keywords takes a long time, the user will have no indication whether Vim is actually working on something or has stopped responding.

        Personally I'd rather wait for 2 seconds knowing that Vim is actively processing multiple files, than wonder after 30 seconds whether Vim is almost done or whether I should just kill it with <C-C> and type stuff manually.

        --
        --
        You received this message from the "vim_dev" maillist.
        Do not top-post! Type your reply below the text you are replying to.
        For more information, visit http://www.vim.org/maillist.php

        ---
        You received this message because you are subscribed to the Google Groups "vim_dev" group.
        To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
        For more options, visit https://groups.google.com/groups/opt_out.
      • Gary Johnson
        ... I ll second that. My only experience with slow keyword completion was on a development system where vim was running locally but all the source files were
        Message 3 of 4 , Jan 14 11:01 AM
          On 2014-01-14, Ben Fritz wrote:
          > On Tuesday, January 14, 2014 11:23:53 AM UTC-6, parcs wrote:
          > > I wonder if instead of printing "Scanning %s" for each buffer in
          > > the session during keyword completion, Vim could instead print
          > > say "Scanning buffers." just once. This would reduce the amount
          > > of screen updates performed during keyword completion, thereby
          > > making keyword completion more responsive under slow
          > > terminals/networks.
          > >
          >
          > But with that method, whether on a local PC or over SSH, if there
          > are a lot of LARGE buffers so that scanning for keywords takes a
          > long time, the user will have no indication whether Vim is
          > actually working on something or has stopped responding.
          >
          > Personally I'd rather wait for 2 seconds knowing that Vim is
          > actively processing multiple files, than wonder after 30 seconds
          > whether Vim is almost done or whether I should just kill it with
          > <C-C> and type stuff manually.

          I'll second that. My only experience with slow keyword completion
          was on a development system where vim was running locally but all
          the source files were on a remote file system. The slow updates of
          the "Scanning" messages and the names of the files being scanned was
          my clue to the cause of the problem.

          Regards,
          Gary

          --
          --
          You received this message from the "vim_dev" maillist.
          Do not top-post! Type your reply below the text you are replying to.
          For more information, visit http://www.vim.org/maillist.php

          ---
          You received this message because you are subscribed to the Google Groups "vim_dev" group.
          To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
          For more options, visit https://groups.google.com/groups/opt_out.
        • Bram Moolenaar
          ... What s done with :vimgrep is that Vim prints a message every second, so that the user knows it s still busy. That avoids printing a lot of text you can t
          Message 4 of 4 , Jan 14 12:45 PM
            Patric wrote:

            > I noticed that in sessions with many (100+) small buffers, keyword
            > completion over a slow network causes a 2+ second hiccup. I think
            > this is because during keyword completion, Vim prints the line
            > "Scanning %s" for each open buffer into the command line. When
            > buffers are small (and therefore keyword scanning is very fast), these
            > screen updates happen very quickly one after another and create a
            > spike in network traffic which causes the underlying SSH session to be
            > unresponsive until all screen updates are accounted for.
            >
            > I wonder if instead of printing "Scanning %s" for each buffer in the
            > session during keyword completion, Vim could instead print say
            > "Scanning buffers." just once. This would reduce the amount of screen
            > updates performed during keyword completion, thereby making keyword
            > completion more responsive under slow terminals/networks.
            >
            > Here's a candidate patch that implements the above suggestion.

            What's done with :vimgrep is that Vim prints a message every second, so
            that the user knows it's still busy. That avoids printing a lot of text
            you can't read anyway, and still remains informative.

            See quickfix.c, around line 3260.


            --
            You're as much use as a condom machine at the Vatican.
            -- Rimmer to Holly in Red Dwarf 'Queeg'

            /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
            /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
            \\\ an exciting new programming language -- http://www.Zimbu.org ///
            \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

            --
            --
            You received this message from the "vim_dev" maillist.
            Do not top-post! Type your reply below the text you are replying to.
            For more information, visit http://www.vim.org/maillist.php

            ---
            You received this message because you are subscribed to the Google Groups "vim_dev" group.
            To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
            For more options, visit https://groups.google.com/groups/opt_out.
          Your message has been successfully submitted and would be delivered to recipients shortly.