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

Reply via email to