Alexei Alexandrov wrote:

> 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)

It sounds like keeping only 1024 bytes would already work for most
situations.  That would be an acceptable amount to keep allocated at
all times.  So why don't we use this as the initial size, and when it
grows larger we free it when finished.  The growth size can be doubled
each time perhaps.

> 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.

Right, this may happen and stack size wil greatly depend on the line

> 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%.

That's very useful, thanks for diving into this.

>From "know your smileys":
 8<}}   Glasses, big nose, beard

 /// Bram Moolenaar -- [EMAIL PROTECTED] --   \\\
///        sponsor Vim, vote for features -- \\\
\\\        download, build and distribute --        ///
 \\\            help me help AIDS victims --    ///

Reply via email to