Excerpts from Vlad Irnov's message of Mon Mar 18 11:16:51 +0100 2013: > On 3/15/13, Marc Weber <[email protected]> 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 [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
