Hi Bram Moolenaar, you wrote:
Speed should be OK this way, but it does keep up to 32 Kbyte allocated.
That may not seem much, but if we do this in many places it quickly adds
up.
Any keep limit greater than initial size (e.g. 16384 bytes) will give the
same effect in many cases. By many cases here I mean cases when the stack
just doesn't grow more than 512 bytes (very usual for syntax highlighting). Is
16384 still too big? Regexp matching and syntax highlighting is one of the most
important things in VIM so maybe it's tolerable? Also, as far as I understand,
previosly (version 6) VIM used program stack as regstack, right? Compared with
program stack solution current solution with the change proposed is much better
because program stack never shrinks - once it grows to 1M, for example, the
memory won't be ever given back. At least, this is so on Windows, Linux and I
guess most Unixes.
Can you show the benchmarks you used to see the performance and the
stack space that is being used? Otherwise we keep guessing the best
numbers.
OK. Platform used for investigations: x86, Windows XP SP 2. Pentium 4
Northwood, 2.4 GHz, 512M RAM.
I did 2 things: understanding stack usage and performance measurement. To
understand the stack usage I added some simple logging to regexp.c: printing
ga_maxlen before regstack and backpos clearing and forced the arrays to have
the grow size 1 (so that ga_maxlen will be high watermark in bytes). Of course,
for performance investigations I used version with normal grow size and without
logging.
The version with logging was used to perform the following:
1. With syntax highlighting on, the following files were viewed from gg to G
(with PgDn) and the following high watermark of stack size was observed:
spell.c (444 bytes), $VIMRUNTIME/filetype.vim (820 bytes), big text file with a
lot of syntax errors (252 bytes)
2. Command
gvim -c vimgrep /a\(.\)*z/ *.c | q
was executed in VIM 7 source directory. Stack watermark - 31008 bytes. This is
example of non-optimal regexp which tends to take a lot of stack space.
Similar other test cases were tried leading to the following conclusions: 1)
there is a lot of vim_regexec_both calls during syntax highlighting which work
in very shallow stacks (1K); 2) when user searches for something with regexp
there are cases when regular expression can require big amount of memory (10K).
The performance measurements were done against original version (7.0.188) and
modified regexp.c (initial: 8192, keep limit: 16384). Each measurement was
performed 3 times, minimal time was picked up.
First, I test the syntax highlighting speed:
Command: gvim.exe -f $VIMRUNTIME/filetype.vim -c for i in range(199) | redraw!
| endfor | q
Original version: 10.6 seconds
Modified version: 8.5 seconds
The difference is about 25%.
Second, I did some grepping through Vim sources again:
Command: gvim.exe -c vimgrep /a.*z/ *.c | q
Original version: 6.6 seconds
Modified version: 5.6 seconds
The difference is about 15%.
Coding detail: please don't use if (!number), use if (number == 0),
that is so much easier to read. Checking if ga_data is NULL would be
simpler.
Got it - no problem.
--
Alexei Alexandrov
