On 06/06/2013 10:38, Bram Moolenaar wrote:
Dominique Pelle wrote:
eBram Moolenaar wrote:
You can enable the profiler in the Makefile. The one using Gmon only
measures time per function though. I already know that addstate() is
taking most time. Need to try to reduce the number of calls.
Opening this xml file...
http://svn.code.sf.net/p/languagetool/code/trunk/languagetool/languagetool-language-modules/fr/src/main/resources/org/languagetool/rules/fr/grammar.xml
... is slow (apparently because of folding in the vim modeline
of the xml file). Here are the functions that take most time
when profiling with the new engine (regexpengine=0) with
gprof when running:
$ vim -c ':$' -c :redraw -c :q grammar.xml
Flat profile:
Each sample counts as 0.01 seconds.
% cumulative self self total
time seconds seconds calls s/call s/call name
30.14 1.70 1.70 1686454 0.00 0.00 nfa_regmatch
28.01 3.28 1.58 19068887 0.00 0.00 addstate
5.32 3.58 0.30 2551778 0.00 0.00 syn_current_attr
4.08 3.81 0.23 19483875 0.00 0.00 utfc_ptr2len
3.37 4.00 0.19 21931117 0.00 0.00 copy_sub
3.01 4.17 0.17 2197962 0.00 0.00 in_id_list
1.42 4.25 0.08 38020 0.00 0.00 sha256_process
1.24 4.32 0.07 4784 0.00 0.00 do_autocmd_event
1.06 4.38 0.06 5059366 0.00 0.00 lalloc_clear
[...]
Main bottleneck functions nfa_regmatch() and addstate()
are quite big so it's not simple to find obvious optimization
from the profiling result.
Right, we can't tell from this how to improve things.
For comparison, here are the profiling reslts with the old
engine (regexpengine=1):
Flat profile:
Each sample counts as 0.01 seconds.
% cumulative self self total
time seconds seconds calls s/call s/call name
20.30 0.81 0.81 2708411 0.00 0.00 regmatch
12.78 1.32 0.51 2551778 0.00 0.00 syn_current_attr
8.02 1.64 0.32 22460090 0.00 0.00 utfc_ptr2len
[...]
Loading the file and moving page by page of this xml file
is faster with the old engine.
However, near the long line 23745, moving the cursor
is much faster with the new engine.
So good and bad things with the new engine, which
seems expected.
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.
Mike
--
If you don't like my driving, get out of the Bermuda /\\ -UFO sticker
--
--
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.
