Mike Williams wrote: [...]
> > Clearly the new engine is much faster for long lines (>5000 chars). The > > old engine comes to a grinding halt there. > > > > I'm planning to add profiling to syntax patterns, so that we can see > > which pattern is taking most time. This will help both optimizing the > > regexp engine and syntax file authors. > > I have had a quick look using Intel VTune on Windows with the XML file > and the vast majority of the time appears to be spent in calls to > memset() from lalloc_clear() at the start of nfa_regmatch() and lalloc() > through nfa_regcomp_start(). > > This is quick and dirty results from an optimised build with functions > inlined, always fun mapping reported lines back to original source in > that situation. Thanks, that is very useful to know. One problem with the Vim implementation of the NFA engine is that it needs to remember submatches in every state. Other NFA engines can just have a list with state IDs, we need much more space allocated and copied around. I'll have to think about a way to do this more efficiently. Some of the memset()s are probably unnecessary. -- >From "know your smileys": :-& Eating spaghetti /// Bram Moolenaar -- [email protected] -- 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 [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
