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

Re: Increase output buffer size

Expand Messages
  • Bram Moolenaar
    ... The purpose of the output buffer is not to avoid flicker. It s to avoid many small updates, which is slow. Computers have much more memory now, thus we
    Message 1 of 4 , Aug 2 3:32 AM
    • 0 Attachment
      Ben Schmidt wrote:

      > On 29/07/12 11:41 PM, Balazs Kezes wrote:
      > > My vim seems to flicker on big terminals because the output buffer is
      > > limited to 2K. Outputting a full redraw of large screen needs much more
      > > characters (especially if it has lots of colors). Currently it is
      > > distributed to several writes (separated by several milliseconds on my
      > > slow machine). This causes that when I press Page Down for example I can
      > > see the black flicker in bottom part of the terminal.
      > >
      > > I propose increasing this buffer to 64K. So in src/term.c:
      > > -# define OUT_SIZE 2047
      > > +# define OUT_SIZE 65535
      >
      > This sounds like a good idea to me.

      The purpose of the output buffer is not to avoid flicker. It's to avoid
      many small updates, which is slow.

      Computers have much more memory now, thus we could make the buffer
      bigger. But they are also much faster, thus the need for reducing the
      number of calls is smaller. I suppose making it 8K would be OK.

      I'm mainly worried about slow remote connections. Personally that's
      where I sometimes have problems (ssh over GPRS). I'm not sure what the
      relation is between the buffer size and responsiveness. While typing
      out_flush() should be called quite often.


      --
      % cat /usr/include/sys/errno.h
      #define EPERM 1 /* Operation not permitted */
      #define ENOENT 2 /* No such file or directory */
      #define ESRCH 3 /* No such process */
      [...]
      #define EMACS 666 /* Too many macros */
      %

      /// 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
    • Balazs
      ... I m even doubting a bit that 64K is enough for all cases. Maybe a configuration option for this size would be better (defaulting to 64K but others can
      Message 2 of 4 , Aug 2 11:07 PM
      • 0 Attachment
        > Computers have much more memory now, thus we could make the buffer
        > bigger. [...] I suppose making it 8K would be OK.

        I'm even doubting a bit that 64K is enough for all cases. Maybe a
        configuration option for this size would be better (defaulting to 64K
        but others can reduce/increase the size depending on their needs)?

        > But they are also much faster, thus the need for reducing the number
        > of calls is smaller.

        Yeah, they are faster, but mine is slow enough that I see the partial
        update on most terminals. :(

        > I'm mainly worried about slow remote connections. Personally that's
        > where I sometimes have problems (ssh over GPRS).

        I think that's where this change would shine! Suppose that vim does a
        full screen update (e.g. you press page down) and this means outputting
        13K bytes to the terminal. Vim does the update quite quickly but
        depending on your TCP settings and the time between the actual writes
        this might happen: In the 2K buffer size case the operating system sees
        a bunch of 2K buffers and this might result a bunch of partial packets
        whereas 13K would ensure that the packets are always full length thus it
        should need less packets to transmit the full update.

        > I'm not sure what the relation is between the buffer size and
        > responsiveness. While typing out_flush() should be called quite
        > often.

        It is called quite often already. Vim won't wait for the buffer to fill
        when you append a character to a line. That's only a several character
        update and because you can see that the character is immediately
        outputted it means the output buffer is flushed often.

        My only problem is when vim does a full screen update, that's the only
        case when a 2K buffer is not enough (it is enough for any other update).

        Thanks!

        Balazs

        --
        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
      Your message has been successfully submitted and would be delivered to recipients shortly.