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

Re: Why is Vimscript/VimL much slower than Python when traversing long lists?

Expand Messages
  • Vlad Irnov
    ... Saying that VimL is slow is pointless without explaining exactly what is slow(er) and by how much. I am not aware of any actual comparisons of VimL
    Message 1 of 8 , Mar 18, 2013
      On 3/15/13, Marc Weber <marco-oweber@...> wrote:
      > VimL is known to be slow.

      Saying that VimL is slow is pointless without explaining exactly what is
      slow(er) and by how much. I am not aware of any actual comparisons of
      VimL performance vs other scripting languages. My own conclusion from
      very few crude tests is that VimL can be much slower than Python when
      dealing with long lists and strings, 20 to 100 times slower. In terms of
      actual execution times this only begins to matter with sizes >100000
      items. Using map(), filter(), etc. instead of "for" loop help somewhat.
      Not everything is slow, :g/pattern/... is fast.


      > If you know that you need speed use python or external tools.
      >
      > Why is it the way it is? I don't know.
      >
      > Eventually wait for better replies.
      >
      > I can recommend using a disnict .py file for writing python because then
      > you get all python support (syntax, completion, etc).
      >
      > If you want to learn how a .py file can be found by path have a look at
      > github.com/MarcWeber/scion-backend-vim
      >
      > let s:self=expand('<sfile>:h')

      I use Python a lot in my VOoM plugin. You are absolutely right that any
      substantial Python code should be in distinct .py files instead of
      inside .vim files.


      > You may also want to use a str quoting function like this:
      >
      > def vimQuote(s):
      > return '"%s"' % s.replace("\\","\\\\").replace('"', '\\"').replace("\n",
      > "\\n")
      >
      > because python's to str comes only close (maybe I should retry the to
      > json implementation and find out when whether it fails)
      >
      > Marc Weber

      I usually do
      "'%s'" % s.replace("'","''")

      Regards,
      Vlad

      --
      --
      You received this message from the "vim_use" 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_use" group.
      To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@....
      For more options, visit https://groups.google.com/groups/opt_out.
    • Marc Weber
      ... I ve tried hacking a delphi completion once. Even though using aggressive caching in VimL completion was slower than 1sec. The other thing I tried is
      Message 2 of 8 , Mar 18, 2013
        Excerpts from Vlad Irnov's message of Mon Mar 18 11:16:51 +0100 2013:
        > On 3/15/13, Marc Weber <marco-oweber@...> wrote:
        > > VimL is known to be slow.
        > Saying that VimL is slow is pointless without explaining exactly what is
        > slow(er) and by how much.

        I've tried hacking a delphi completion once. Even though using
        aggressive caching in VimL completion was slower than 1sec.

        The other thing I tried is parsing viml files, to implement a tag like
        goto function feature and more - it also takes more than 15 sec to parse
        and cache all .vim files the first time .

        Such implementations horribly fail on large source bases such as flex
        sdk (actionscript).

        Sorry - I don't know what exactly is slow - and I don't care.

        My impression of UltiSnips vs snipmate (viml) is the same: that the
        python implementation is faster.

        No, its not an accurate benchmark. And to be honest I don't care.
        Same about YouCompleteMe vs NeoComplCache (YouCompleteMe is written in C
        for a strong reason: speed).

        Applying regex to many lines is likely to be one point - but there might
        be more.

        Whenever you have huge amounts of data don't use viml unless you can use
        viml builtins (this also applies to :g :v vs :!%grep etc)

        You're right that it could be possible to optimize VimL and identify the
        problems (split or join was one which got fixed). But I don't have time
        to do so - if other solutions already work.

        Marc Weber

        --
        --
        You received this message from the "vim_use" 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_use" group.
        To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@....
        For more options, visit https://groups.google.com/groups/opt_out.
      Your message has been successfully submitted and would be delivered to recipients shortly.