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

Slowdowns caused by bracket matching

Expand Messages
  • björn
    Hi, I have found another case that sometimes (not always) causes slowdowns in MacVim. While editing a tex file with ~300 lines in noticed that typing was slow
    Message 1 of 8 , Oct 14, 2007
    • 0 Attachment
      Hi,

      I have found another case that sometimes (not always) causes slowdowns
      in MacVim. While editing a tex file with ~300 lines in noticed that
      typing was slow when the cursor was just before a bracket of some
      sort.

      For example, if I first type

      \usepackage{}

      and then position the cursor on the "{", hit 'a', and start typing.
      Then MacVim felt sluggish. On the other hand if I type

      \usepackage{xz}

      and then position the cursor on the 'x', hit 'a', and start typing.
      Then everything was fast again. (Starting from the 'z' would make
      things slow again.)

      Thus the slowdowns have something to do with the bracket
      matching...but I don't understand what could cause this. I started
      editing a new (empty) file, entered "{}" and started typing in between
      the brackets, but in this case no slowdown was noticeable. Also,
      after ":syntax off" the first scenario was fast again.

      I guess it could be the text drawing that causes this slowdown, but
      maybe somebody has a better explanation?


      /Björn

      --~--~---------~--~----~------------~-------~--~----~
      You received this message from the "vim_mac" maillist.
      For more information, visit http://www.vim.org/maillist.php
      -~----------~----~----~----~------~----~------~--~---
    • björn
      ... Well, I just noticed that disabling the matchparen plugin gets rid of the problem (:NoMatchParen). Why would matchparen cause such extremely noticable
      Message 2 of 8 , Oct 14, 2007
      • 0 Attachment
        > Thus the slowdowns have something to do with the bracket
        > matching...but I don't understand what could cause this. I started
        > editing a new (empty) file, entered "{}" and started typing in between
        > the brackets, but in this case no slowdown was noticeable. Also,
        > after ":syntax off" the first scenario was fast again.
        >
        > I guess it could be the text drawing that causes this slowdown, but
        > maybe somebody has a better explanation?

        Well, I just noticed that disabling the "matchparen" plugin gets rid
        of the problem (:NoMatchParen). Why would "matchparen" cause such
        extremely noticable problems?


        /Björn

        --~--~---------~--~----~------------~-------~--~----~
        You received this message from the "vim_mac" maillist.
        For more information, visit http://www.vim.org/maillist.php
        -~----------~----~----~----~------~----~------~--~---
      • Bram Moolenaar
        ... The matchparen plugin has two parts: finding the matching paren and highlighting it. It might be that the highlighting causes the problem. To figure out
        Message 3 of 8 , Oct 14, 2007
        • 0 Attachment
          Björn Winckler wrote:

          > > Thus the slowdowns have something to do with the bracket
          > > matching...but I don't understand what could cause this. I started
          > > editing a new (empty) file, entered "{}" and started typing in between
          > > the brackets, but in this case no slowdown was noticeable. Also,
          > > after ":syntax off" the first scenario was fast again.
          > >
          > > I guess it could be the text drawing that causes this slowdown, but
          > > maybe somebody has a better explanation?
          >
          > Well, I just noticed that disabling the "matchparen" plugin gets rid
          > of the problem (:NoMatchParen). Why would "matchparen" cause such
          > extremely noticable problems?

          The matchparen plugin has two parts: finding the matching paren and
          highlighting it. It might be that the highlighting causes the problem.
          To figure out if this is true, or that it's the finding after all, you
          could change the matchparen plugin to do the finding but skip the
          highlighting.

          If the highlighting is the problem then your display updating code needs
          to be improved...

          --
          How To Keep A Healthy Level Of Insanity:
          12. Sing along at the opera.

          /// 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 ///

          --~--~---------~--~----~------------~-------~--~----~
          You received this message from the "vim_mac" maillist.
          For more information, visit http://www.vim.org/maillist.php
          -~----------~----~----~----~------~----~------~--~---
        • björn
          ... If I comment out the match commands in matchparen.vim then everything runs at an acceptable speed. With the match commands everything is slow again,
          Message 4 of 8 , Oct 20, 2007
          • 0 Attachment
            On 14/10/2007, Bram Moolenaar <Bram@...> wrote:
            >
            > Björn Winckler wrote:
            >
            > > > Thus the slowdowns have something to do with the bracket
            > > > matching...but I don't understand what could cause this. I started
            > > > editing a new (empty) file, entered "{}" and started typing in between
            > > > the brackets, but in this case no slowdown was noticeable. Also,
            > > > after ":syntax off" the first scenario was fast again.
            > > >
            > > > I guess it could be the text drawing that causes this slowdown, but
            > > > maybe somebody has a better explanation?
            > >
            > > Well, I just noticed that disabling the "matchparen" plugin gets rid
            > > of the problem (:NoMatchParen). Why would "matchparen" cause such
            > > extremely noticable problems?
            >
            > The matchparen plugin has two parts: finding the matching paren and
            > highlighting it. It might be that the highlighting causes the problem.
            > To figure out if this is true, or that it's the finding after all, you
            > could change the matchparen plugin to do the finding but skip the
            > highlighting.
            >
            > If the highlighting is the problem then your display updating code needs
            > to be improved...

            If I comment out the "match" commands in matchparen.vim then
            everything runs at an acceptable speed. With the "match" commands
            everything is slow again, so the display updating code must be the
            problem.


            /Björn

            --~--~---------~--~----~------------~-------~--~----~
            You received this message from the "vim_mac" maillist.
            For more information, visit http://www.vim.org/maillist.php
            -~----------~----~----~----~------~----~------~--~---
          • björn
            ... I spent some more time profiling the drawing code only to come to the conclusion that it is not the MacVim drawing routines (MMTextStorage et al.) that are
            Message 5 of 8 , Oct 27, 2007
            • 0 Attachment
              On 20/10/2007, björn <bjorn.winckler@...> wrote:
              > On 14/10/2007, Bram Moolenaar <Bram@...> wrote:
              > >
              > > Björn Winckler wrote:
              > >
              > > > > Thus the slowdowns have something to do with the bracket
              > > > > matching...but I don't understand what could cause this. I started
              > > > > editing a new (empty) file, entered "{}" and started typing in between
              > > > > the brackets, but in this case no slowdown was noticeable. Also,
              > > > > after ":syntax off" the first scenario was fast again.
              > > > >
              > > > > I guess it could be the text drawing that causes this slowdown, but
              > > > > maybe somebody has a better explanation?
              > > >
              > > > Well, I just noticed that disabling the "matchparen" plugin gets rid
              > > > of the problem (:NoMatchParen). Why would "matchparen" cause such
              > > > extremely noticable problems?
              > >
              > > The matchparen plugin has two parts: finding the matching paren and
              > > highlighting it. It might be that the highlighting causes the problem.
              > > To figure out if this is true, or that it's the finding after all, you
              > > could change the matchparen plugin to do the finding but skip the
              > > highlighting.
              > >
              > > If the highlighting is the problem then your display updating code needs
              > > to be improved...
              >
              > If I comment out the "match" commands in matchparen.vim then
              > everything runs at an acceptable speed. With the "match" commands
              > everything is slow again, so the display updating code must be the
              > problem.

              I spent some more time profiling the drawing code only to come to the
              conclusion that it is not the MacVim drawing routines (MMTextStorage
              et al.) that are causing the slowdowns when "matchparen" is enabled.

              Here is what I did:

              1. I disabled all the highlighting code in MacVim so that syntax on or
              off makes no difference...the same thing is rendered (no colors etc.).
              Still, matchparen causes slowdowns. [this indicates that there is not
              much to optimize here]

              2. Trace drawing calls made with and without matchparen. This showed
              that occasionally matchparen throws in a couple of extra draw
              commands, but nothing major. [nothing much to do here either. btw, I
              implemented a "pruning" algorithm, which removed unnecessary draw
              calls (calls that draw on top of each other) but this makes no
              noticeable difference to speed even though quite a lot of calls
              sometimes get removed.]

              3. Ran Shark (sampling all threads) while frantically hitting keys on
              the keyboard. Shark tells me that the CPU time is spent as follows:
              WITH matchparen : Vim ~50% : Idle process ~25% : MacVim ~15%
              WITHOUT matchparen: MacVim ~35% : Idle process ~30% : Vim ~20%

              Something seems to be going on in Vim when matchparen enabled. Here
              is where the time is spent inside Vim:

              # Report 6 - Session 8 - Time Profile of Everything
              SharkProfileViewer
              # Generated from the visible portion of the outline view
              - 11.5% regmatch (Vim)
              - 10.6% utfc_ptr2len (Vim)
              - 8.7% vim_strchr (Vim)
              - 2.5% in_id_list (Vim)
              - 2.4% syn_current_attr (Vim)
              - 1.8% utf_ptr2char (Vim)
              - 1.7% szone_free (libSystem.B.dylib)
              - 1.6% fast_breakcheck (Vim)
              - 1.5% regtry (Vim)
              - 1.5% 0xffff8600 [192B] (Unknown Library)
              - 1.5% vim_regexec_both (Vim)
              - 1.5% ml_set_interrupts_enabled (mach_kernel)
              - 1.3% do_one_cmd (Vim)
              - 1.2% eval_isnamec (Vim)
              - 1.2% regstack_push (Vim)
              - 1.2% szone_malloc (libSystem.B.dylib)
              - 1.2% reg_restore (Vim)
              - 1.1% find_name_end (Vim)
              - snip -

              I'm not sure if I should really start optimizing anything inside Vim,
              but it seems to me that there is little I can do inside MacVim to
              improve speed when matchparen is enabled.

              Is it a known problem that the syntax highlighting routines can be
              slow? Has anybody looked into improving these routines?


              /Björn

              --~--~---------~--~----~------------~-------~--~----~
              You received this message from the "vim_mac" maillist.
              For more information, visit http://www.vim.org/maillist.php
              -~----------~----~----~----~------~----~------~--~---
            • björn
              I m sorry that I keep replying to my own posts several times, but I think this might be interesting so... ... As it turns out one problem spot is
              Message 6 of 8 , Oct 28, 2007
              • 0 Attachment
                I'm sorry that I keep replying to my own posts several times, but I
                think this might be interesting so...

                On 27/10/2007, björn <bjorn.winckler@...> wrote:
                > On 20/10/2007, björn <bjorn.winckler@...> wrote:
                > > On 14/10/2007, Bram Moolenaar <Bram@...> wrote:
                > > >
                > > > Björn Winckler wrote:
                > > >
                > > > > > Thus the slowdowns have something to do with the bracket
                > > > > > matching...but I don't understand what could cause this. I started
                > > > > > editing a new (empty) file, entered "{}" and started typing in between
                > > > > > the brackets, but in this case no slowdown was noticeable. Also,
                > > > > > after ":syntax off" the first scenario was fast again.
                > > > > >
                > > > > > I guess it could be the text drawing that causes this slowdown, but
                > > > > > maybe somebody has a better explanation?
                > > > >
                > > > > Well, I just noticed that disabling the "matchparen" plugin gets rid
                > > > > of the problem (:NoMatchParen). Why would "matchparen" cause such
                > > > > extremely noticable problems?
                > > >
                > > > The matchparen plugin has two parts: finding the matching paren and
                > > > highlighting it. It might be that the highlighting causes the problem.
                > > > To figure out if this is true, or that it's the finding after all, you
                > > > could change the matchparen plugin to do the finding but skip the
                > > > highlighting.
                > > >
                > > > If the highlighting is the problem then your display updating code needs
                > > > to be improved...
                > >
                > > If I comment out the "match" commands in matchparen.vim then
                > > everything runs at an acceptable speed. With the "match" commands
                > > everything is slow again, so the display updating code must be the
                > > problem.
                >
                > I spent some more time profiling the drawing code only to come to the
                > conclusion that it is not the MacVim drawing routines (MMTextStorage
                > et al.) that are causing the slowdowns when "matchparen" is enabled.
                >
                > Here is what I did:
                >
                > 1. I disabled all the highlighting code in MacVim so that syntax on or
                > off makes no difference...the same thing is rendered (no colors etc.).
                > Still, matchparen causes slowdowns. [this indicates that there is not
                > much to optimize here]
                >
                > 2. Trace drawing calls made with and without matchparen. This showed
                > that occasionally matchparen throws in a couple of extra draw
                > commands, but nothing major. [nothing much to do here either. btw, I
                > implemented a "pruning" algorithm, which removed unnecessary draw
                > calls (calls that draw on top of each other) but this makes no
                > noticeable difference to speed even though quite a lot of calls
                > sometimes get removed.]
                >
                > 3. Ran Shark (sampling all threads) while frantically hitting keys on
                > the keyboard. Shark tells me that the CPU time is spent as follows:
                > WITH matchparen : Vim ~50% : Idle process ~25% : MacVim ~15%
                > WITHOUT matchparen: MacVim ~35% : Idle process ~30% : Vim ~20%
                >
                > Something seems to be going on in Vim when matchparen enabled. Here
                > is where the time is spent inside Vim:
                >
                > # Report 6 - Session 8 - Time Profile of Everything
                > SharkProfileViewer
                > # Generated from the visible portion of the outline view
                > - 11.5% regmatch (Vim)
                > - 10.6% utfc_ptr2len (Vim)
                > - 8.7% vim_strchr (Vim)
                > - 2.5% in_id_list (Vim)
                > - 2.4% syn_current_attr (Vim)
                > - 1.8% utf_ptr2char (Vim)
                > - 1.7% szone_free (libSystem.B.dylib)
                > - 1.6% fast_breakcheck (Vim)
                > - 1.5% regtry (Vim)
                > - 1.5% 0xffff8600 [192B] (Unknown Library)
                > - 1.5% vim_regexec_both (Vim)
                > - 1.5% ml_set_interrupts_enabled (mach_kernel)
                > - 1.3% do_one_cmd (Vim)
                > - 1.2% eval_isnamec (Vim)
                > - 1.2% regstack_push (Vim)
                > - 1.2% szone_malloc (libSystem.B.dylib)
                > - 1.2% reg_restore (Vim)
                > - 1.1% find_name_end (Vim)
                > - snip -
                >
                > I'm not sure if I should really start optimizing anything inside Vim,
                > but it seems to me that there is little I can do inside MacVim to
                > improve speed when matchparen is enabled.
                >
                > Is it a known problem that the syntax highlighting routines can be
                > slow? Has anybody looked into improving these routines?

                As it turns out one problem spot is gui_mch_update()...this didn't
                turn up in my first profiling attempts, but today I noticed that it
                did show up so I did some investigation (it gets called a lot when
                regmatch() is called).

                1. gui_mch_update() sometimes gets called as often as 10 times per ms
                (on average) and it is quite normal that it is called 1 time per ms
                whilst typing (fast)

                2. gui_mch_update() checks the run loop for new events and this is a
                slow operation (I didn't time it so I have no exact figures)

                Similar to what is done in gui_mch_flush() I now check that
                gui_mch_update() only checks the run loop every 100 ms or so. This
                results in a very noticeable speed increase when 'matchparen' is
                enabled (at least on my machine). I've pushed this patch to the
                public repo in case anybody wants to try it out.

                My test case for checking the speed increase is a latex document with
                ~400 lines, then I go to the "\begin{document}" line, put the cursor
                on '}', hit 'i' and start hitting keys frantically. Without the patch
                this made text output "stutter", with the patch things run fairly
                smooth.

                I also tried opening $VIMRUNTIME/colors/slate.vim and it does seem to
                render a bit faster than previously (I may be imagining things here
                though).

                Does anybody else notice any improvements to speed?


                /Björn

                --~--~---------~--~----~------------~-------~--~----~
                You received this message from the "vim_mac" maillist.
                For more information, visit http://www.vim.org/maillist.php
                -~----------~----~----~----~------~----~------~--~---
              • björn
                ... I ve found an even worse example: open mbyte.c line 1194, put cursor on the } , press i and start typing. Argh! (To those of you who don t dare
                Message 7 of 8 , Nov 1, 2007
                • 0 Attachment
                  > > 3. Ran Shark (sampling all threads) while frantically hitting keys on
                  > > the keyboard. Shark tells me that the CPU time is spent as follows:
                  > > WITH matchparen : Vim ~50% : Idle process ~25% : MacVim ~15%
                  > > WITHOUT matchparen: MacVim ~35% : Idle process ~30% : Vim ~20%

                  I've found an even worse example: open mbyte.c line 1194, put cursor
                  on the '}', press 'i' and start typing. Argh! (To those of you who
                  don't dare trying...the "frame rate" goes down to something like 1
                  Hz.)

                  I tried opening the same file in Carbon Vim and vim-cocoa. Carbon Vim
                  is awfully slow but better than MacVim, vim-cocoa on the other hand is
                  as slow as MacVim. Can anybody offer me an explanation as to what's
                  going on here? It is interesting to see that both MacVim and
                  vim-cocoa are so slow.

                  I profiled vim-cocoa same way as I did MacVim and most time is spent
                  in regmatch() (~25%). Oh, and when profiling MacVim with this file
                  almost 90% of the processor time is spent inside the Vim process!

                  Again, without matchparen enabled everything is just fine. I strongly
                  advice anybody running into performance problems to disable
                  matchparen. Bram: should I try to see if I can optimize Vim or is
                  there something else that can be done to make matchparen behave?


                  /Björn

                  --~--~---------~--~----~------------~-------~--~----~
                  You received this message from the "vim_mac" maillist.
                  For more information, visit http://www.vim.org/maillist.php
                  -~----------~----~----~----~------~----~------~--~---
                • Bram Moolenaar
                  ... Well, there are probably ways to make matchparen go faster, but you should still try to solve the problem in Macvim. The same behavior can happen with
                  Message 8 of 8 , Nov 1, 2007
                  • 0 Attachment
                    Björn Winckler wrote:

                    > > > 3. Ran Shark (sampling all threads) while frantically hitting keys on
                    > > > the keyboard. Shark tells me that the CPU time is spent as follows:
                    > > > WITH matchparen : Vim ~50% : Idle process ~25% : MacVim ~15%
                    > > > WITHOUT matchparen: MacVim ~35% : Idle process ~30% : Vim ~20%
                    >
                    > I've found an even worse example: open mbyte.c line 1194, put cursor
                    > on the '}', press 'i' and start typing. Argh! (To those of you who
                    > don't dare trying...the "frame rate" goes down to something like 1
                    > Hz.)
                    >
                    > I tried opening the same file in Carbon Vim and vim-cocoa. Carbon Vim
                    > is awfully slow but better than MacVim, vim-cocoa on the other hand is
                    > as slow as MacVim. Can anybody offer me an explanation as to what's
                    > going on here? It is interesting to see that both MacVim and
                    > vim-cocoa are so slow.
                    >
                    > I profiled vim-cocoa same way as I did MacVim and most time is spent
                    > in regmatch() (~25%). Oh, and when profiling MacVim with this file
                    > almost 90% of the processor time is spent inside the Vim process!
                    >
                    > Again, without matchparen enabled everything is just fine. I strongly
                    > advice anybody running into performance problems to disable
                    > matchparen. Bram: should I try to see if I can optimize Vim or is
                    > there something else that can be done to make matchparen behave?

                    Well, there are probably ways to make matchparen go faster, but you
                    should still try to solve the problem in Macvim. The same behavior can
                    happen with another plugin.

                    --
                    hundred-and-one symptoms of being an internet addict:
                    77. The phone company asks you to test drive their new PBX system

                    /// 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 ///

                    --~--~---------~--~----~------------~-------~--~----~
                    You received this message from the "vim_mac" maillist.
                    For more information, visit http://www.vim.org/maillist.php
                    -~----------~----~----~----~------~----~------~--~---
                  Your message has been successfully submitted and would be delivered to recipients shortly.