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

Re: Extremely slow when using relativenumber & syntax highlighting

Expand Messages
  • Christian Brabandt
    [fullquote, since copying vim-dev] ... You might have found a bug here. I think the original idea is, that whenever relativenumber is set, one needs to
    Message 1 of 6 , Mar 27 12:37 AM
    • 0 Attachment
      [fullquote, since copying vim-dev]
      Am 2014-03-27 00:05, schrieb Dominique Pellé:
      > patrick hemmer wrote:
      >
      >> Whenever I have relative line number on (relativenumber), and
      >> syntax highlighting enabled (syntax on), moving the cursor is
      >> painfully slow. Not only moving between lines, but just moving
      >> the cursor left/right on the same line.
      >>
      >> I've tried removing my local .vim & .vimrc files as well as the
      >> ones in /etc to have a completely default config. As soon as
      >> I `syntax on` and `set rnu`, it starts exhibiting the issue.
      >>
      >> It doesn't seem to do this on all files though, just most. As a
      >> reliable way to duplicate the issue, I can copy the http://yaml.org
      >> web page content into a .yaml file, and edit that.
      >> But I get it in multiple languages, perl, yaml, ruby, & other.
      >>
      >> Version 7.4 with patches 1-193 (though I've had this behavior for
      >> years with older versions).
      >
      >
      > I can reproduce the slowness using the yaml file copied
      > from http://yaml.org
      >
      > Here are some timings with and without relativenumber
      > when moving 50 times horizontally with l and h:
      >
      > $ time vim -u NONE foo.yaml \
      > -c 'set relativenumber' \
      > -c 'syntax on' +10 \
      > -c 'call
      > feedkeys("llllllllllhhhhhhhhhhllllllllllhhhhhhhhhhllllllllll:q\<CR>")'
      > real 0m4.677s
      > user 0m1.447s
      > sys 0m3.226s
      > --> slow!
      >
      > $ time vim -u NONE foo.yaml \
      > -c 'set norelativenumber' \
      > -c 'syntax on' +10 \
      > -c 'call
      > feedkeys("llllllllllhhhhhhhhhhllllllllllhhhhhhhhhhllllllllll:q\<CR>")'
      > real 0m0.166s
      > user 0m0.086s
      > sys 0m0.077s
      > --> fast
      >
      > If I use ":syntime on" and ":syntime report", I see this:
      >
      > With relativenumber:
      >
      > TOTAL COUNT MATCH SLOWEST AVERAGE NAME
      > PATTERN
      > 3.706423 7752 7395 0.002521 0.000478 yamlPlainScalar
      > \%([\-?:,\[\]{}#&*!|>'"%@`]\@!\%(\%([\n\r\uFEFF
      > \t]\)\@!\p\)\|[?:\-]\%(\%(\%([\n\r\uFEFF \t]\)\@!\p\)\)\@=
      > 1.105733 4029 2040 0.000742 0.000274 yamlFloat
      > \%([\[\]{},
      > \t]\@!\p\)\@<!\%([+-]\=\%(\%(\d[0-9_]*\)\.[0-9_]*\%([eE][+-]\d\+\)\=\|\.[0-9_]\+\%([eE][-+][0-
      > 0.711836 1224 0 0.001174 0.000582 yamlBlockMappingKey
      > \%#=1\s*\zs\%([\-?:,\[\]{}#&*!|>'"%@`]\@!\%(\%([\n\r\uFEFF
      > \t]\)\@!\p\)\|[?:\-]\%(\%(\%([\n\r\uFEFF \t]\)\
      >
      > 0.481088 2703 153 0.000815 0.000178 yamlInteger
      > \%([\[\]{},
      > \t]\@!\p\)\@<!\%([+-]\=\%(0\%(b[0-1_]\+\|[0-7_]\+\|x[0-9a-fA-F_]\+\)\=\|\%([1-9][0-9_]*\%(:[0-
      > 0.044233 2601 0 0.000042 0.000017 yamlTimestamp
      > \%([\[\]{},
      > \t]\@!\p\)\@<!\%(\d\{4}-\d\d\=-\d\d\=\%(\%([Tt]\|\s\+\)\%(\d\d\=\):\%(\d\d\):\%(\d\d\)\%(\.\%(
      > 0.038902 2652 408 0.000056 0.000015 yamlBlockMappingKey
      > \%#=1^\s*\zs\%([\-?:,\[\]{}#&*!|>'"%@`]\@!\%(\%([\n\r\uFEFF
      > \t]\)\@!\p\)\|[?:\-]\%(\%(\%([\n\r\uFEFF \t]\)
      >
      > 0.023793 3825 2448 0.000029 0.000006 yamlComment
      > \%\(^\|\s\)#
      > 0.007552 3825 1224 0.000009 0.000002
      > yamlBlockCollectionItemStart ^\s*\zs-\%(\s\+-\)*\s
      > 0.006340 2601 0 0.000009 0.000002
      > yamlBlockMappingMerge ^\s*\zs<<\ze:\%(\s\|$\)
      > 0.004530 1224 1224 0.000008 0.000004 yamlComment $
      > 0.003572 2601 0 0.000008 0.000001 yamlDocumentEnd
      > ^\.\.\.\ze\%(\s\|$\)
      > 0.002253 2601 0 0.000003 0.000001 yamlFlowCollection \[
      > 0.002248 2601 51 0.000031 0.000001 yamlDirective
      > ^\ze%\%(\%([\n\r\uFEFF \t]\)\@!\p\)\+\s\+
      > 0.002189 2601 51 0.000004 0.000001 yamlDocumentStart
      > ^---\ze\%(\s\|$\)
      > 0.001827 2601 0 0.000025 0.000001 yamlConstant
      > \<\~\>
      > 0.001594 2601 0 0.000019 0.000001 yamlMappingKeyStart
      > ?\ze\s
      > 0.001468 2703 255 0.000002 0.000001 yamlFlowString "
      > 0.001446 2652 51 0.000002 0.000001 yamlFlowString '
      > 0.001407 2601 0 0.000013 0.000001 yamlAlias
      > \*\%(\%([\n\r\uFEFF \t,\[\]{}]\)\@!\p\)\+
      > 0.001404 2601 0 0.000002 0.000001 yamlFlowMapping {
      > 0.001372 2601 0 0.000002 0.000001 yamlAnchor
      > &\%(\%([\n\r\uFEFF \t,\[\]{}]\)\@!\p\)\+
      > 0.001313 2601 0 0.000002 0.000001 yamlNodeTag
      > !<\%(%\x\x\|\%(\w\|-\)\|[#/;?:@&=+$,.!~*''()\[\]]\)\+>\|\%(!\%(\w\|-\)\+!\|!!\|!\)\%(%\x\x\|\%(\w\|-\)\|[#
      > 0.000839 1224 0 0.000002 0.000001
      > yamlBlockMappingMerge <<\ze\s*:\%(\s\|$\)
      > 0.000823 408 408 0.000005 0.000002 yamlKeyValueDelimiter
      > \s*:
      > 0.000506 408 408 0.000003 0.000001 yamlKeyValueDelimiter
      > \s*:
      > 0.000503 51 0 0.000011 0.000010
      > yamlReservedDirective %\%(\%(TAG\|YAML\)\s\)\@!\%(\%([\n\r\uFEFF
      > \t]\)\@!\p\)\+
      > 0.000147 51 51 0.000004 0.000003 yamlYAMLVersion
      > \d\+\.\d\+
      > 0.000128 51 51 0.000003 0.000003 yamlYAMLDirective
      > %YAML\s\+
      > 0.000121 51 51 0.000003 0.000002 yamlDirective $
      > 0.000078 51 0 0.000002 0.000002 yamlTAGDirective
      > %TAG\s\+
      > 0.000062 102 102 0.000001 0.000001 yamlFlowString "
      > 0.000052 102 0 0.000001 0.000001 yamlFlowString
      > \\"
      > 0.000028 51 0 0.000001 0.000001 yamlEscape
      > \\\%([\\"abefnrtv\^0_ NLP\n]\|x\x\x\|u\x\{4}\|U\x\{8}\)
      >
      > 6.155810 66351
      >
      >
      > Without relative number:
      >
      > TOTAL COUNT MATCH SLOWEST AVERAGE NAME
      > PATTERN
      > 0.071678 152 145 0.001796 0.000472 yamlPlainScalar
      > \%([\-?:,\[\]{}#&*!|>'"%@`]\@!\%(\%([\n\r\uFEFF
      > \t]\)\@!\p\)\|[?:\-]\%(\%(\%([\n\r\uFEFF \t]\)\@!\p\)\)\@=
      > 0.021474 79 40 0.000679 0.000272 yamlFloat
      > \%([\[\]{},
      > \t]\@!\p\)\@<!\%([+-]\=\%(\%(\d[0-9_]*\)\.[0-9_]*\%([eE][+-]\d\+\)\=\|\.[0-9_]\+\%([eE][-+][0-
      > 0.013851 24 0 0.001121 0.000577 yamlBlockMappingKey
      > \%#=1\s*\zs\%([\-?:,\[\]{}#&*!|>'"%@`]\@!\%(\%([\n\r\uFEFF
      > \t]\)\@!\p\)\|[?:\-]\%(\%(\%([\n\r\uFEFF \t]\)\
      >
      > 0.009354 53 3 0.000627 0.000176 yamlInteger
      > \%([\[\]{},
      > \t]\@!\p\)\@<!\%([+-]\=\%(0\%(b[0-1_]\+\|[0-7_]\+\|x[0-9a-fA-F_]\+\)\=\|\%([1-9][0-9_]*\%(:[0-
      > 0.000884 51 0 0.000029 0.000017 yamlTimestamp
      > \%([\[\]{},
      > \t]\@!\p\)\@<!\%(\d\{4}-\d\d\=-\d\d\=\%(\%([Tt]\|\s\+\)\%(\d\d\=\):\%(\d\d\):\%(\d\d\)\%(\.\%(
      > 0.000778 52 8 0.000055 0.000015 yamlBlockMappingKey
      > \%#=1^\s*\zs\%([\-?:,\[\]{}#&*!|>'"%@`]\@!\%(\%([\n\r\uFEFF
      > \t]\)\@!\p\)\|[?:\-]\%(\%(\%([\n\r\uFEFF \t]\)
      >
      > 0.000469 75 48 0.000024 0.000006 yamlComment
      > \%\(^\|\s\)#
      > 0.000150 75 24 0.000014 0.000002
      > yamlBlockCollectionItemStart ^\s*\zs-\%(\s\+-\)*\s
      > 0.000115 51 0 0.000004 0.000002
      > yamlBlockMappingMerge ^\s*\zs<<\ze:\%(\s\|$\)
      > 0.000088 24 24 0.000005 0.000004 yamlComment $
      > 0.000074 51 0 0.000004 0.000001 yamlDocumentEnd
      > ^\.\.\.\ze\%(\s\|$\)
      > 0.000046 51 1 0.000021 0.000001 yamlDirective
      > ^\ze%\%(\%([\n\r\uFEFF \t]\)\@!\p\)\+\s\+
      > 0.000044 51 0 0.000001 0.000001 yamlFlowCollection \[
      > 0.000043 51 1 0.000004 0.000001 yamlDocumentStart
      > ^---\ze\%(\s\|$\)
      > 0.000036 51 0 0.000001 0.000001 yamlConstant
      > \<\~\>
      > 0.000032 52 1 0.000001 0.000001 yamlFlowString '
      > 0.000032 51 0 0.000001 0.000001 yamlFlowMapping {
      > 0.000032 51 0 0.000002 0.000001 yamlMappingKeyStart
      > ?\ze\s
      > 0.000032 51 0 0.000001 0.000001 yamlAnchor
      > &\%(\%([\n\r\uFEFF \t,\[\]{}]\)\@!\p\)\+
      > 0.000032 51 0 0.000001 0.000001 yamlAlias
      > \*\%(\%([\n\r\uFEFF \t,\[\]{}]\)\@!\p\)\+
      > 0.000026 53 5 0.000001 0.000000 yamlFlowString "
      > 0.000018 51 0 0.000001 0.000000 yamlNodeTag
      > !<\%(%\x\x\|\%(\w\|-\)\|[#/;?:@&=+$,.!~*''()\[\]]\)\+>\|\%(!\%(\w\|-\)\+!\|!!\|!\)\%(%\x\x\|\%(\w\|-\)\|[#
      > 0.000017 24 0 0.000001 0.000001
      > yamlBlockMappingMerge <<\ze\s*:\%(\s\|$\)
      > 0.000017 8 8 0.000003 0.000002 yamlKeyValueDelimiter
      > \s*:
      > 0.000011 1 0 0.000011 0.000011
      > yamlReservedDirective %\%(\%(TAG\|YAML\)\s\)\@!\%(\%([\n\r\uFEFF
      > \t]\)\@!\p\)\+
      > 0.000009 8 8 0.000002 0.000001 yamlKeyValueDelimiter
      > \s*:
      > 0.000003 1 1 0.000003 0.000003 yamlDirective $
      > 0.000003 1 1 0.000003 0.000003 yamlYAMLVersion
      > \d\+\.\d\+
      > 0.000002 1 1 0.000002 0.000002 yamlYAMLDirective
      > %YAML\s\+
      > 0.000002 2 0 0.000001 0.000001 yamlFlowString
      > \\"
      > 0.000001 1 0 0.000001 0.000001 yamlTAGDirective
      > %TAG\s\+
      > 0.000000 2 2 0.000000 0.000000 yamlFlowString "
      > 0.000000 1 0 0.000000 0.000000 yamlEscape
      > \\\%([\\"abefnrtv\^0_ NLP\n]\|x\x\x\|u\x\{4}\|U\x\{8}\)
      >
      > 0.119353 1301
      >
      > So somehow regexp are being checked far more often
      > when relativenumber is on, which does not seem right
      > considering that the command mostly moves horizontally.
      >
      > Using callgrind, I see that:
      > * with 'norelativenumber', update_screen() was called only once
      > * with 'relativenumber', update_screen() was called 51 times
      >
      > Notice that the command I used was moving:
      > - 50 times horizontally with h and l
      > - 1 time vertically using +10
      >
      > This means that with relativenumber, update_screen() gets
      > called each time we move horizontally with h or l which does
      > not seem needed at first sight.
      >
      > The code that seems responsible for the spurious redraw is:
      > move.c:1190 (commenting that line as a experiment makes it fast)
      > so the logic to decide whether to redraw is wrong but I can't see
      > how to fix it:
      >
      > 1175 /* Redraw when w_row changes and 'relativenumber' is set */
      > 1176 if (((curwin->w_valid & VALID_WROW) == 0 && (curwin->w_p_rnu
      > 1177 #ifdef FEAT_SYN_HL
      > 1178 /* or when w_row changes and 'cursorline' is set. */
      > 1179 || curwin->w_p_cul
      > 1180 #endif
      > 1181 ))
      > 1182 #ifdef FEAT_SYN_HL
      > 1183 /* or when w_virtcol changes and 'cursorcolumn' is set */
      > 1184 || (curwin->w_p_cuc && (curwin->w_valid & VALID_VIRTCOL)
      > == 0)
      > 1185 #endif
      > 1186 )
      > 1187 # ifdef FEAT_INS_EXPAND
      > 1188 if (!pum_visible())
      > 1189 # endif
      > 1190 redraw_later(SOME_VALID);
      >
      > I'm using Vim-7.4.218 on Linux x86_64 in the xfce4-terminal.

      You might have found a bug here. I think the original idea is, that
      whenever 'relativenumber'
      is set, one needs to update more often, since the relativenumbers change
      whenever you move
      the cursor up and down. This does obviously not happen here and I think
      this is caused
      by curwin->w_valid incorrectly being made invalid.

      I don't see why VALID_WROW should be made invalid, just because the
      column changed. So I remove it in the following
      patch and after testing with your commandline given above Vim indeed
      seems to be much faster (but please
      everybody test to confirm).

      diff --git a/src/move.c b/src/move.c
      --- a/src/move.c
      +++ b/src/move.c
      @@ -467,7 +467,7 @@ check_cursor_moved(wp)
      #endif
      )
      {
      - wp->w_valid &= ~(VALID_WROW|VALID_WCOL|VALID_VIRTCOL);
      + wp->w_valid &= ~(VALID_WCOL|VALID_VIRTCOL);
      wp->w_valid_cursor.col = wp->w_cursor.col;
      wp->w_valid_leftcol = wp->w_leftcol;
      #ifdef FEAT_VIRTUALEDIT


      Best,
      Christian

      --
      --
      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/d/optout.
    • Bram Moolenaar
      ... That will cause a problem for long lines. I ll make an alternative patch. -- You can test a person s importance in the organization by asking how much RAM
      Message 2 of 6 , Mar 27 4:13 AM
      • 0 Attachment
        Christian Brabandt wrote:

        > You might have found a bug here. I think the original idea is, that
        > whenever 'relativenumber'
        > is set, one needs to update more often, since the relativenumbers change
        > whenever you move
        > the cursor up and down. This does obviously not happen here and I think
        > this is caused
        > by curwin->w_valid incorrectly being made invalid.
        >
        > I don't see why VALID_WROW should be made invalid, just because the
        > column changed. So I remove it in the following
        > patch and after testing with your commandline given above Vim indeed
        > seems to be much faster (but please
        > everybody test to confirm).
        >
        > diff --git a/src/move.c b/src/move.c
        > --- a/src/move.c
        > +++ b/src/move.c
        > @@ -467,7 +467,7 @@ check_cursor_moved(wp)
        > #endif
        > )
        > {
        > - wp->w_valid &= ~(VALID_WROW|VALID_WCOL|VALID_VIRTCOL);
        > + wp->w_valid &= ~(VALID_WCOL|VALID_VIRTCOL);
        > wp->w_valid_cursor.col = wp->w_cursor.col;
        > wp->w_valid_leftcol = wp->w_leftcol;
        > #ifdef FEAT_VIRTUALEDIT
        >

        That will cause a problem for long lines. I'll make an alternative
        patch.

        --
        You can test a person's importance in the organization by asking how much RAM
        his computer has. Anybody who knows the answer to that question is not a
        decision-maker.
        (Scott Adams - The Dilbert principle)

        /// 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/d/optout.
      • Christian Brabandt
        [copying Zyx, as he is the maintainer of the syntax script] ... [...] ... Those patterns are crazy. Here is a patch, that deviates the performance issue
        Message 3 of 6 , Mar 27 8:56 AM
        • 0 Attachment
          [copying Zyx, as he is the maintainer of the syntax script]
          Am 2014-03-27 00:05, schrieb Dominique Pellé:
          > I can reproduce the slowness using the yaml file copied
          > from http://yaml.org
          [...]
          >
          > If I use ":syntime on" and ":syntime report", I see this:
          >
          > With relativenumber:
          >
          > TOTAL COUNT MATCH SLOWEST AVERAGE NAME
          > PATTERN
          > 3.706423 7752 7395 0.002521 0.000478 yamlPlainScalar
          > \%([\-?:,\[\]{}#&*!|>'"%@`]\@!\%(\%([\n\r\uFEFF
          > \t]\)\@!\p\)\|[?:\-]\%(\%(\%([\n\r\uFEFF \t]\)\@!\p\)\)\@=
          > 1.105733 4029 2040 0.000742 0.000274 yamlFloat
          > \%([\[\]{},
          > \t]\@!\p\)\@<!\%([+-]\=\%(\%(\d[0-9_]*\)\.[0-9_]*\%([eE][+-]\d\+\)\=\|\.[0-9_]\+\%([eE][-+][0-
          > 0.711836 1224 0 0.001174 0.000582 yamlBlockMappingKey
          > \%#=1\s*\zs\%([\-?:,\[\]{}#&*!|>'"%@`]\@!\%(\%([\n\r\uFEFF
          > \t]\)\@!\p\)\|[?:\-]\%(\%(\%([\n\r\uFEFF \t]\)\
          >
          > 0.481088 2703 153 0.000815 0.000178 yamlInteger
          > \%([\[\]{},
          > \t]\@!\p\)\@<!\%([+-]\=\%(0\%(b[0-1_]\+\|[0-7_]\+\|x[0-9a-fA-F_]\+\)\=\|\%([1-9][0-9_]*\%(:[0-
          > 0.044233 2601 0 0.000042 0.000017 yamlTimestamp
          > \%([\[\]{},
          > \t]\@!\p\)\@<!\%(\d\{4}-\d\d\=-\d\d\=\%(\%([Tt]\|\s\+\)\%(\d\d\=\):\%(\d\d\):\%(\d\d\)\%(\.\%(
          > 0.038902 2652 408 0.000056 0.000015 yamlBlockMappingKey
          > \%#=1^\s*\zs\%([\-?:,\[\]{}#&*!|>'"%@`]\@!\%(\%([\n\r\uFEFF
          > \t]\)\@!\p\)\|[?:\-]\%(\%(\%([\n\r\uFEFF \t]\)

          Those patterns are crazy. Here is a patch, that deviates the performance
          issue slightly
          (mainly by making sure, the old 're' engine is used in place of those
          high performance syntax
          items and by limiting the look-around assertion). This fixes the
          performance penalties
          even more but might make syntax highlighting more inaccurate (although I
          used a conservative
          limit of 100 bytes).

          Also, I noticed, the syntax script is missing some :syn sync rules. I am
          not sure, what the default
          is, but some clever syn rules could also improve syntax performance
          slightly.

          Best,
          Christian

          --
          --
          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/d/optout.
        • Nikolay Pavlov
          ... PATTERN ... t] @! p ) @
          Message 4 of 6 , Mar 27 9:07 AM
          • 0 Attachment


            On Mar 27, 2014 7:56 PM, "Christian Brabandt" <cblists@...> wrote:
            >
            > [copying Zyx, as he is the maintainer of the syntax script]
            >
            > Am 2014-03-27 00:05, schrieb Dominique Pellé:
            >>
            >> I can reproduce the slowness using the yaml file copied
            >> from http://yaml.org
            >
            > [...]
            >
            >>
            >> If I use ":syntime on" and ":syntime report", I see this:
            >>
            >> With relativenumber:
            >>
            >>   TOTAL      COUNT  MATCH   SLOWEST     AVERAGE   NAME               PATTERN
            >>   3.706423   7752   7395    0.002521    0.000478  yamlPlainScalar
            >> \%([\-?:,\[\]{}#&*!|>'"%@`]\@!\%(\%([\n\r\uFEFF
            >> \t]\)\@!\p\)\|[?:\-]\%(\%(\%([\n\r\uFEFF \t]\)\@!\p\)\)\@=
            >>   1.105733   4029   2040    0.000742    0.000274  yamlFloat
            >> \%([\[\]{},
            >> \t]\@!\p\)\@<!\%([+-]\=\%(\%(\d[0-9_]*\)\.[0-9_]*\%([eE][+-]\d\+\)\=\|\.[0-9_]\+\%([eE][-+][0-
            >>   0.711836   1224   0       0.001174    0.000582  yamlBlockMappingKey
            >> \%#=1\s*\zs\%([\-?:,\[\]{}#&*!|>'"%@`]\@!\%(\%([\n\r\uFEFF
            >> \t]\)\@!\p\)\|[?:\-]\%(\%(\%([\n\r\uFEFF \t]\)\
            >>
            >>   0.481088   2703   153     0.000815    0.000178  yamlInteger
            >> \%([\[\]{},
            >> \t]\@!\p\)\@<!\%([+-]\=\%(0\%(b[0-1_]\+\|[0-7_]\+\|x[0-9a-fA-F_]\+\)\=\|\%([1-9][0-9_]*\%(:[0-
            >>   0.044233   2601   0       0.000042    0.000017  yamlTimestamp
            >> \%([\[\]{},
            >> \t]\@!\p\)\@<!\%(\d\{4}-\d\d\=-\d\d\=\%(\%([Tt]\|\s\+\)\%(\d\d\=\):\%(\d\d\):\%(\d\d\)\%(\.\%(
            >>   0.038902   2652   408     0.000056    0.000015  yamlBlockMappingKey
            >> \%#=1^\s*\zs\%([\-?:,\[\]{}#&*!|>'"%@`]\@!\%(\%([\n\r\uFEFF
            >> \t]\)\@!\p\)\|[?:\-]\%(\%(\%([\n\r\uFEFF \t]\)
            >
            >
            > Those patterns are crazy. Here is a patch, that deviates the performance issue slightly
            > (mainly by making sure, the old 're' engine is used in place of those high performance syntax
            > items and by limiting the look-around assertion). This fixes the performance penalties
            > even more but might make syntax highlighting more inaccurate (although I used a conservative
            > limit of 100 bytes).

            If I understand these limits correctly it can be limited to an exact amount of bytes: AFAIR I was using only fixed-width lookarounds (making these limits be possible to be deduced by re engine). At least this patch touches only fixed-width lookarounds. Though I may understand these limits not correctly.

            >
            > Also, I noticed, the syntax script is missing some :syn sync rules. I am not sure, what the default
            > is, but some clever syn rules could also improve syntax performance slightly.
            >
            > Best,
            > Christian

            --
            --
            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/d/optout.
          • Adam
            On an unrelated note, you may want to consider setting synmaxcol to a reasonable value as that can drastically improve performance if you regularly deal with
            Message 5 of 6 , Mar 27 2:18 PM
            • 0 Attachment
              On an unrelated note, you may want to consider setting synmaxcol to a reasonable value as that can drastically improve performance if you regularly deal with very long lines (with syntax highlighting enabled for the current buffer).

              ~Adam~

              --
              --
              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/d/optout.
            • Bram Moolenaar
              ... It was already included. Get the latest version. -- I wonder how much deeper the ocean would be without sponges. /// Bram Moolenaar -- Bram@Moolenaar.net
              Message 6 of 6 , Apr 8, 2014
              • 0 Attachment
                Patrick Hemmer wrote:

                > So I enabled the 'lazyredraw' option which immensely helps vertical
                > movement. However horizontal movement is still terrible (and it makes
                > it so I cant see the cursor while holding down "l" or "h").
                >
                > Also setting regexpengine=1 was a significant performance boost as
                > well. I was experiencing a lot of slowdowns especially with ruby and
                > yaml files, but setting regexpengine=1 significantly sped those up.
                > Still not completely smooth, but it is better.
                >
                >
                > On Thursday, March 27, 2014 7:13:06 AM UTC-4, Bram Moolenaar wrote:
                > > Christian Brabandt wrote:
                > > > diff --git a/src/move.c b/src/move.c
                > > > --- a/src/move.c
                > > > +++ b/src/move.c
                > > > @@ -467,7 +467,7 @@ check_cursor_moved(wp)
                > > > #endif
                > > > )
                > > > {
                > > > - wp->w_valid &= ~(VALID_WROW|VALID_WCOL|VALID_VIRTCOL);
                > > > + wp->w_valid &= ~(VALID_WCOL|VALID_VIRTCOL);
                > > > wp->w_valid_cursor.col = wp->w_cursor.col;
                > > > wp->w_valid_leftcol = wp->w_leftcol;
                > > > #ifdef FEAT_VIRTUALEDIT
                > > >
                > >
                > >
                > > That will cause a problem for long lines. I'll make an alternative
                > > patch.
                >
                > I would still be interested in this patch if it was made.

                It was already included. Get the latest version.

                --
                I wonder how much deeper the ocean would be without sponges.

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