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

Re: Vim 7 performance notes

Expand Messages
  • Alexei Alexandrov
    ... Forgot the attachment. -- Alexei Alexandrov
    Message 1 of 30 , Feb 7, 2007
    • 0 Attachment
      Hi Alexei Alexandrov, you wrote:

      >
      > The program which confirms these numbers is attached.
      >
      Forgot the attachment.

      --
      Alexei Alexandrov
    • Mikolaj Machowski
      ... When testing it with VST it gave 3.4% speed improvements (the same metodology - 3 tests before and after, choose the best results). m.
      Message 2 of 30 , Feb 7, 2007
      • 0 Attachment
        Dnia środa 07 luty 2007, Alexei Alexandrov napisał:
        > Hi Mikolaj Machowski, you wrote:
        > > Nice work. Could you send or place somewhere patches? I'd like to test
        > > them on more complex regexps.
        >
        > Here it is. Note that the biggest speed-up is observed when regexp is
        > matched a lot of times. The regexp mechanism itself is not affected at
        > all here - so if you have one regexp which runs very long you won't
        > probably notice any major difference.

        When testing it with VST it gave 3.4% speed improvements (the same
        metodology - 3 tests before and after, choose the best results).

        m.
      • Alexei Alexandrov
        ... Well, it s not that much but it s still positive result. :-) -- Alexei Alexandrov
        Message 3 of 30 , Feb 8, 2007
        • 0 Attachment
          Hi Mikolaj Machowski, you wrote:

          >
          > When testing it with VST it gave 3.4% speed improvements (the same
          > metodology - 3 tests before and after, choose the best results).
          >

          Well, it's not that much but it's still positive result. :-)

          --
          Alexei Alexandrov
        • Nikolai Weibull
          ... Considering how intense these computations are and how often they are performed (probably the most time-consuming part of Vim), any improvement will help a
          Message 4 of 30 , Feb 8, 2007
          • 0 Attachment
            On 2/8/07, Alexei Alexandrov <alexei.alexandrov@...> wrote:

            > > When testing it with VST it gave 3.4% speed improvements (the same
            > > metodology - 3 tests before and after, choose the best results).

            > Well, it's not that much but it's still positive result. :-)

            Considering how intense these computations are and how often they are
            performed (probably the most time-consuming part of Vim), any
            improvement will help a lot.

            It's nice to see people alongside Bram working on improving Vim. Your
            work is highly appreciated (as well ;-).

            nikolai
          • Bram Moolenaar
            ... I would not assume it s similar until there is proof. ... This sounds like a bug in getc(). It should know that only one thread is reading the file and
            Message 5 of 30 , Feb 8, 2007
            • 0 Attachment
              Alexei Alexandrov wrote:

              > I've also noticed that Vim spends somewhat significant time on startup
              > loading spell files (I have 2 languages in my .vimrc: set
              > spelllang=en,ru). The time is mostly spent in
              > EnterCriticalSection/LeaveCriticalSection with getc() upper the stack.
              > The reason for this is CRT blocking since the runtime is
              > multithreaded. It's Windows, but on Linux it should be similar.

              I would not assume it's similar until there is proof.

              > As far as I understand, Vim doesn't access the spell file from
              > multiple threads. Thus, the situation can be improved a lot: on Linux
              > by using getc_unlocked. On Windows, starting VS 2005 there is a
              > function _getc_nolock. Before VS 2005 this function can be emulated by
              > macro:
              >
              > #define _getc_nolock(_stream) (--(_stream)->_cnt >= 0 ? \
              > 0xff & *(_stream)->_ptr++ : _filbuf(_stream))
              >
              > By switching to non-blocking getc() in spell.c I was able to reduce
              > Vim startup time from about 0.9 seconds to about 0.7 seconds.

              This sounds like a bug in getc(). It should know that only one thread
              is reading the file and skip the locking. I don't think we should fix
              library bugs in Vim, unless it's crashing or another significant problem.

              Perhaps you can already get a big increase by not compiling for
              debugging? With MSVC this usually has a big impact. Also largely
              defeats profiling with debugging enabled.

              --
              From "know your smileys":
              :-E Has major dental problems

              /// 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 ///
            • Alexei Alexandrov
              ... Of course. I m going to investigate it there. ... It can t be a bug. I might be missing what you mean, but I can t see how it can know that only one thread
              Message 6 of 30 , Feb 10, 2007
              • 0 Attachment
                Hi Bram Moolenaar, you wrote:

                >> It's Windows, but on Linux it should be similar.
                >
                > I would not assume it's similar until there is proof.
                >
                Of course. I'm going to investigate it there.

                >
                > This sounds like a bug in getc(). It should know that only one thread
                > is reading the file and skip the locking. I don't think we should fix
                > library bugs in Vim, unless it's crashing or another significant problem.
                >
                It can't be a bug. I might be missing what you mean, but I can't see how it can know that only one thread is reading a file. It doesn't have a clue whether you gave this FILE * to other threads or not. It tries to be lightweight - as I described in a separate mail it uses InterlockedIncrement/Decrement but they are not that lightweight - they don't require switching to kernel mode but still take about 200 cycles of CPU each.

                The only optimization that I see could be avoiding blocking (and even trying to block) in case if there is only one thread in current process and if there is guarantee that this particular call is guaranteed not to create any threads. But 1) it still may be expensive and 2) Vim has some background threads anyway, probably.

                > Perhaps you can already get a big increase by not compiling for
                > debugging? With MSVC this usually has a big impact. Also largely
                > defeats profiling with debugging enabled.
                >
                I do _all_ performance measurements using optimized version of binary with symbols. This is just a must for performance tuning.

                --
                Alexei Alexandrov
              • Bram Moolenaar
                ... Hmm, getc() is apparently preparing for the worst and isn t optimized for the 98% of the situations where there is only one thread reading from the fd.
                Message 7 of 30 , Feb 10, 2007
                • 0 Attachment
                  Alexei Alexandrov wrote:

                  > > This sounds like a bug in getc(). It should know that only one thread
                  > > is reading the file and skip the locking. I don't think we should fix
                  > > library bugs in Vim, unless it's crashing or another significant problem.
                  > >
                  > It can't be a bug. I might be missing what you mean, but I can't see
                  > how it can know that only one thread is reading a file. It doesn't
                  > have a clue whether you gave this FILE * to other threads or not. It
                  > tries to be lightweight - as I described in a separate mail it uses
                  > InterlockedIncrement/Decrement but they are not that lightweight -
                  > they don't require switching to kernel mode but still take about 200
                  > cycles of CPU each.
                  >
                  > The only optimization that I see could be avoiding blocking (and even
                  > trying to block) in case if there is only one thread in current
                  > process and if there is guarantee that this particular call is
                  > guaranteed not to create any threads. But 1) it still may be expensive
                  > and 2) Vim has some background threads anyway, probably.

                  Hmm, getc() is apparently preparing for the worst and isn't optimized
                  for the 98% of the situations where there is only one thread reading
                  from the fd. With the result that the, very often used, getc() is slow.

                  Besides using getc_unlocked() we could use read() and do our own
                  buffering. That can't bee very complicated. And we don't need to
                  figure out if the getc_unlocked() function is available.


                  --
                  hundred-and-one symptoms of being an internet addict:
                  102. When filling out your driver's license application, you give
                  your IP address.

                  /// 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 ///
                • Alexei Alexandrov
                  ... I chose 8192/16384 pair because it s the closest to original 10000 bytes. 10000 itself would also be fine but I like round numbers... The patch with
                  Message 8 of 30 , Feb 10, 2007
                  • 0 Attachment
                    Hi Bram Moolenaar, you wrote:

                    >
                    > It sounds like keeping only 1024 bytes would already work for most
                    > situations. That would be an acceptable amount to keep allocated at
                    > all times. So why don't we use this as the initial size, and when it
                    > grows larger we free it when finished. The growth size can be doubled
                    > each time perhaps.
                    >

                    I chose 8192/16384 pair because it's the closest to original 10000 bytes. 10000 itself would also be fine but I like round numbers...

                    The patch with changes which, I think, close to what you describe above is attached. Could you please take a look at it?

                    >
                    > Right, this may happen and stack size wil greatly depend on the line
                    > length.
                    >
                    ...
                    >
                    > That's very useful, thanks for diving into this.
                    >

                    My pleasure.

                    --
                    Alexei Alexandrov
                  • Bram Moolenaar
                    ... It s starting to look better, less disadvantages and should still give a fair speedup. 10000 bytes is OK for when it s going to be freed again soon. If
                    Message 9 of 30 , Feb 10, 2007
                    • 0 Attachment
                      Alexei Alexandrov wrote:

                      > Hi Bram Moolenaar, you wrote:
                      >
                      > >
                      > > It sounds like keeping only 1024 bytes would already work for most
                      > > situations. That would be an acceptable amount to keep allocated at
                      > > all times. So why don't we use this as the initial size, and when it
                      > > grows larger we free it when finished. The growth size can be doubled
                      > > each time perhaps.
                      >
                      > I chose 8192/16384 pair because it's the closest to original 10000
                      > bytes. 10000 itself would also be fine but I like round numbers...
                      >
                      > The patch with changes which, I think, close to what you describe
                      > above is attached. Could you please take a look at it?

                      It's starting to look better, less disadvantages and should still give a
                      fair speedup.

                      10000 bytes is OK for when it's going to be freed again soon. If you
                      want to keep the memory allocated something less would be more
                      appropriate. And thus you need to start low, but could increase it in
                      larger steps (since it's going to be freed on return anyway).

                      The growarray is used in lots of places. Adding another field to it
                      will cause more memory to be used. Isn't it easier to make another
                      version of ga_grow() that increases the growsize when allocating another
                      block?

                      Instead of doubling each time, which is going to be big chunks quickly,
                      another way would be to first allocate one block at the start size of
                      about 1000 bytes, then set the growsize to 10000. So we grow at the
                      same speed as before. Then no extra field or function is needed, it's
                      local change in the regexp code.

                      Something like:
                      if (regstack.ga_data == NULL)
                      {
                      ga_init2(®stack, 1, 1000);
                      ga_grow(®stack, 1);
                      }
                      regstack.ga_growsize = 10000;

                      I do wonder if the memory needs to be cleared when re-using the
                      allocated memory. Can you check that?

                      --
                      A meeting is an event at which the minutes are kept and the hours are lost.

                      /// 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 ///
                    • Alexei Alexandrov
                      Bram Moolenaar wrote: Instead of doubling each time, which is going to be big chunks quickly, another way would be to first allocate one block at the
                      Message 10 of 30 , Oct 2, 2007
                      • 0 Attachment
                        Bram Moolenaar wrote:

                        >
                        > Instead of doubling each time, which is going to be big chunks quickly,
                        > another way would be to first allocate one block at the start size of
                        > about 1000 bytes, then set the growsize to 10000. So we grow at the
                        > same speed as before. Then no extra field or function is needed, it's
                        > local change in the regexp code.
                        >
                        > Something like:
                        > if (regstack.ga_data == NULL)
                        > {
                        > ga_init2(®stack, 1, 1000);
                        > ga_grow(®stack, 1);
                        > }
                        > regstack.ga_growsize = 10000;
                        >
                        > I do wonder if the memory needs to be cleared when re-using the
                        > allocated memory. Can you check that?
                        >

                        I'd like to get back to this topic - after I use my patch for half a
                        year without a problem.

                        The patch is attached. It addresses your comments fully. Please take a look.

                        Regarding cleaning the stacks - from what I can tell from the code, it's
                        not needed. regmatch() clears the stack heads in the beginning by
                        resetting the len of arrays, and then it uses only the part of the stack
                        it fills.

                        In fact, I also considered moving the stack allocation management
                        directly to regmatch() since the stacks are actually used only there.
                        But it's more cosmetic change and shouldn't affect the functionality in
                        any way (though we may get 2 reallocations per regexec_both call in case
                        of big chunks).

                        So does the patch look like a good one to you? Or will I just live with
                        it here locally? :)


                        --~--~---------~--~----~------------~-------~--~----~
                        You received this message from the "vim_dev" maillist.
                        For more information, visit http://www.vim.org/maillist.php
                        -~----------~----~----~----~------~----~------~--~---
                      • Bram Moolenaar
                        ... The patch looks OK to me. The big question is: how much performance do we gain? There is also another regexp improvement underway, this was part of the
                        Message 11 of 30 , Oct 3, 2007
                        • 0 Attachment
                          Alexei Alexandrov wrote:

                          > > Instead of doubling each time, which is going to be big chunks quickly,
                          > > another way would be to first allocate one block at the start size of
                          > > about 1000 bytes, then set the growsize to 10000. So we grow at the
                          > > same speed as before. Then no extra field or function is needed, it's
                          > > local change in the regexp code.
                          > >
                          > > Something like:
                          > > if (regstack.ga_data == NULL)
                          > > {
                          > > ga_init2(®stack, 1, 1000);
                          > > ga_grow(®stack, 1);
                          > > }
                          > > regstack.ga_growsize = 10000;
                          > >
                          > > I do wonder if the memory needs to be cleared when re-using the
                          > > allocated memory. Can you check that?
                          > >
                          >
                          > I'd like to get back to this topic - after I use my patch for half a
                          > year without a problem.
                          >
                          > The patch is attached. It addresses your comments fully. Please take a look.
                          >
                          > Regarding cleaning the stacks - from what I can tell from the code, it's
                          > not needed. regmatch() clears the stack heads in the beginning by
                          > resetting the len of arrays, and then it uses only the part of the stack
                          > it fills.
                          >
                          > In fact, I also considered moving the stack allocation management
                          > directly to regmatch() since the stacks are actually used only there.
                          > But it's more cosmetic change and shouldn't affect the functionality in
                          > any way (though we may get 2 reallocations per regexec_both call in case
                          > of big chunks).
                          >
                          > So does the patch look like a good one to you? Or will I just live with
                          > it here locally? :)

                          The patch looks OK to me. The big question is: how much performance do
                          we gain?

                          There is also another regexp improvement underway, this was part of the
                          Google summer of code. It would be nice if we have a performance
                          measurement mechanism, so that the regexp stuff can be tuned. A Vim
                          script would be best, so that it can be run everywhere. Perhaps using
                          some of the syntax highlighting, since that uses regexp a lot and
                          provides a real-world situation. Since the actual display updating is
                          not what we want to measure, using the synID() function might work.
                          Combined with ":syn sync fromstart".

                          --
                          ARTHUR: Now stand aside worthy adversary.
                          BLACK KNIGHT: (Glancing at his shoulder) 'Tis but a scratch.
                          ARTHUR: A scratch? Your arm's off.
                          "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

                          /// 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_dev" maillist.
                          For more information, visit http://www.vim.org/maillist.php
                          -~----------~----~----~----~------~----~------~--~---
                        • Mikolaj Machowski
                          ... I repeated tests done in Feb. The same methodology. Vim 7.1.135 Script: VST. Three profiles before patch, three profiles after patch. Difference between
                          Message 12 of 30 , Oct 3, 2007
                          • 0 Attachment
                            Dnia środa 03 październik 2007, Bram Moolenaar napisał:
                            > > So does the patch look like a good one to you? Or will I just live
                            > > with it here locally? :)
                            >
                            > The patch looks OK to me. The big question is: how much performance do
                            > we gain?

                            I repeated tests done in Feb. The same methodology.

                            Vim 7.1.135
                            Script: VST.
                            Three profiles before patch, three profiles after patch.

                            Difference between two best results is 2.2% (comparing with 3.4% from
                            Feb). In addition I compared worst with best:

                            worst pre - best post: 4.7%
                            best pre - worst post: 1.2%

                            Of course all numbers are time gains achieved with regexp-perf patch.

                            m.


                            --~--~---------~--~----~------------~-------~--~----~
                            You received this message from the "vim_dev" maillist.
                            For more information, visit http://www.vim.org/maillist.php
                            -~----------~----~----~----~------~----~------~--~---
                          • Bram Moolenaar
                            ... What do you mean with VST? It would be good to describe this in a way that I can run the same on my system. -- Scientists decoded the first message from
                            Message 13 of 30 , Oct 3, 2007
                            • 0 Attachment
                              Mikolaj Machowski wrote:

                              > Dnia =B6roda 03 pa=BCdziernik 2007, Bram Moolenaar napisa=B3:
                              > > > So does the patch look like a good one to you? Or will I just live
                              > > > with it here locally? :)
                              > >
                              > > The patch looks OK to me. The big question is: how much performance do
                              > > we gain?
                              >
                              > I repeated tests done in Feb. The same methodology.
                              >
                              > Vim 7.1.135
                              > Script: VST.
                              > Three profiles before patch, three profiles after patch.
                              >
                              > Difference between two best results is 2.2% (comparing with 3.4% from
                              > Feb). In addition I compared worst with best:
                              >
                              > worst pre - best post: 4.7%
                              > best pre - worst post: 1.2%
                              >
                              > Of course all numbers are time gains achieved with regexp-perf patch.

                              What do you mean with VST? It would be good to describe this in a way
                              that I can run the same on my system.

                              --
                              Scientists decoded the first message from an alien civilization:
                              SIMPLY SEND 6 TIMES 10 TO THE 50 ATOMS OF HYDROGEN TO THE STAR
                              SYSTEM AT THE TOP OF THE LIST, CROSS OFF THAT STAR SYSTEM, THEN PUT
                              YOUR STAR SYSTEM AT THE BOTTOM OF THE LIST AND SEND IT TO 100 OTHER
                              STAR SYSTEMS. WITHIN ONE TENTH GALACTIC ROTATION YOU WILL RECEIVE
                              ENOUGH HYDROGREN TO POWER YOUR CIVILIZATION UNTIL ENTROPY REACHES ITS
                              MAXIMUM! IT REALLY WORKS!

                              /// 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_dev" maillist.
                              For more information, visit http://www.vim.org/maillist.php
                              -~----------~----~----~----~------~----~------~--~---
                            • Mikołaj Machowski
                              ... VST - Vim reStructuredText What is it: http://skawina.eu.org/mikolaj/vst.html http://skawina.eu.org/mikolaj/vst.zip Tests were done on vst.txt and with
                              Message 14 of 30 , Oct 4, 2007
                              • 0 Attachment
                                > > Vim 7.1.135
                                > > Script: VST.
                                > > Three profiles before patch, three profiles after patch.
                                > >
                                > > Difference between two best results is 2.2% (comparing with 3.4% from
                                > > Feb). In addition I compared worst with best:
                                > >
                                > > worst pre - best post: 4.7%
                                > > best pre - worst post: 1.2%
                                > >
                                > What do you mean with VST? It would be good to describe this in a way
                                > that I can run the same on my system.
                                >
                                VST - Vim reStructuredText

                                What is it:
                                http://skawina.eu.org/mikolaj/vst.html

                                http://skawina.eu.org/mikolaj/vst.zip

                                Tests were done on vst.txt and with :Vst command

                                m.

                                ----------------------------------------------------
                                Żagle w górę! Mistrzostwa Polski w Match Racingu
                                już 5-7 października w Gdyni!
                                Zobacz więcej:
                                http://klik.wp.pl/?adr=http%3A%2F%2Fcorto.www.wp.pl%2Fas%2Fpolishmatchtour.html&sid=47



                                --~--~---------~--~----~------------~-------~--~----~
                                You received this message from the "vim_dev" maillist.
                                For more information, visit http://www.vim.org/maillist.php
                                -~----------~----~----~----~------~----~------~--~---
                              • Alexei Alexandrov
                                ... OK, so I ll need to prepare some numbers. For now some historical background. I started this performance investigation due to a pathological performance
                                Message 15 of 30 , Oct 4, 2007
                                • 0 Attachment
                                  Bram Moolenaar wrote:
                                  >>
                                  >> So does the patch look like a good one to you? Or will I just live with
                                  >> it here locally? :)
                                  >
                                  > The patch looks OK to me. The big question is: how much performance do
                                  > we gain?
                                  >
                                  > There is also another regexp improvement underway, this was part of the
                                  > Google summer of code. It would be nice if we have a performance
                                  > measurement mechanism, so that the regexp stuff can be tuned. A Vim
                                  > script would be best, so that it can be run everywhere. Perhaps using
                                  > some of the syntax highlighting, since that uses regexp a lot and
                                  > provides a real-world situation. Since the actual display updating is
                                  > not what we want to measure, using the synID() function might work.
                                  > Combined with ":syn sync fromstart".
                                  >

                                  OK, so I'll need to prepare some numbers.

                                  For now some historical background. I started this performance
                                  investigation due to a pathological performance degradation on my VIM
                                  script for coloring rgb.txt file (the file comes in the root of Vim
                                  runtime file tree). I color it so that each line is colored with RGB it
                                  represents. The script is attached.

                                  It creates a big number of highlight groups with short simple matches.
                                  It was light-fast on VIM 6.3 and it became redrawing slo-o-o-w on VIM 7
                                  (after os-stack-based-regexp-stack to heap-based stack change). This is
                                  why I investigated it. So I wouldn't say that it's improvement - it's
                                  actually back to performance of 6.3. Now I need to prove you that it's
                                  actually "back". OK, will do :-)

                                  --
                                  Alexei Alexandrov

                                  --~--~---------~--~----~------------~-------~--~----~
                                  You received this message from the "vim_dev" maillist.
                                  For more information, visit http://www.vim.org/maillist.php
                                  -~----------~----~----~----~------~----~------~--~---
                                • Bram Moolenaar
                                  ... OK, I know about that. I m not sure if this would give a representative performance for regexp use. I would think most people use regexp patterns for
                                  Message 16 of 30 , Oct 4, 2007
                                  • 0 Attachment
                                    Mikolaj Machowski wrote:

                                    > > > Vim 7.1.135
                                    > > > Script: VST.
                                    > > > Three profiles before patch, three profiles after patch.
                                    > > >
                                    > > > Difference between two best results is 2.2% (comparing with 3.4% from
                                    > > > Feb). In addition I compared worst with best:
                                    > > >
                                    > > > worst pre - best post: 4.7%
                                    > > > best pre - worst post: 1.2%
                                    > > >
                                    > > What do you mean with VST? It would be good to describe this in a way
                                    > > that I can run the same on my system.
                                    > >
                                    > VST - Vim reStructuredText
                                    >
                                    > What is it:
                                    > http://skawina.eu.org/mikolaj/vst.html
                                    >
                                    > http://skawina.eu.org/mikolaj/vst.zip
                                    >
                                    > Tests were done on vst.txt and with :Vst command

                                    OK, I know about that. I'm not sure if this would give a representative
                                    performance for regexp use. I would think most people use regexp
                                    patterns for syntax highlighting.

                                    --
                                    Team-building exercises come in many forms but they all trace their roots back
                                    to the prison system. In your typical team-building exercise the employees
                                    are subjected to a variety of unpleasant situations until they become either a
                                    cohesive team or a ring of car jackers.
                                    (Scott Adams - The Dilbert principle)

                                    /// 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_dev" maillist.
                                    For more information, visit http://www.vim.org/maillist.php
                                    -~----------~----~----~----~------~----~------~--~---
                                  Your message has been successfully submitted and would be delivered to recipients shortly.