70145Re: Some performance figures for the new regexp engine
- May 26 4:12 AMMarc Weber wrote:
> If we are at it - and other tools are already faster, is there a chanceAdding another regexp syntax will confuse users. It's too easy to make
> to also add a engine 3 reusing the fast code?
> If we partially break with VimL (by improving python support) why
> not also add a commonly used regex syntax if speed is different.
> I've tried debugging gnugrep which was said to be faster:
> dfasearch.c contains:
> if ((err = re_compile_pattern (p, len,
> &(patterns[pcount].regexbuf))) != NULL)
> I was not able to step into re_compile_pattern, probably because its
> using glibc's re_compile_pattern.
> The problem is that I don't think you can use those regular expressions
> to search for multiline patterns if can be found in different patterns.
> Eg there is re_search_2 which does not work with an internal "regular
> expression matching state", but concatenates two strings:
> /* Like `re_search', but search in the concatenation of STRING1 and
> STRING2. Also, stop searching at index START + STOP. */
> extern int re_search_2 (struct re_pattern_buffer *__buffer,
> const char *__string1, int __length1,
> const char *__string2, int __length2, int __start,
> int __range, struct re_registers *__regs, int __stop);
> PCRE even started jitting:
> and it supports multi-segment matching (which I guess would be required
> to implement vim_regexec_multi ?
> Bram, do you think its worth a try adding pcre support?
> It shouldn't be too hard to translate Vim regular expressions to pcre
> syntax before compiling.
> Why should we continue spending time on maintaining this ourselves?
> I haven't looked at all details but I think adding pcre support is
> straight forward.
Translating one RE syntax into another works for simple things, it's
close to impossible for more complex things. Especially selecting the
right match out of alternatives is not something you can easily do by
changing the pattern. Getting it right for the new engine, which was
specifically made for Vim, already turns out to be very difficult.
The performance of pattern matching overal is good enough. It's only
for syntax highlighting that slowness has been reported. And there we
are using Vim expressions. Considering how slow syntax files are
updated, I don't expect more than a few to switch to another RE syntax.
They would more easily gain speed by optimizing the existing patterns.
The fastest way to get an engineer to solve a problem is to declare that the
problem is unsolvable. No engineer can walk away from an unsolvable problem
until it's solved.
(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/groups/opt_out.
- << Previous post in topic Next post in topic >>