On 4/29/06, Bram Moolenaar <[EMAIL PROTECTED]> wrote:
Yakov Lerner wrote: > I identified which functions are slow and which are fast out of functions > called (load_dummy_buffer() + wipe_dummy_buffer()) pair. > > As I wrote earlier this pair of functions is what slows down vimgrep, > not the search. The loop of 1000x (load_dummy_buffer() + wipe_dummy_buffer(= > )) > takes 30 seconds per 1000 pairs on my machine (800 MHZ). These tests > are on empty files, so data size is not a problem. No regexp searching is > performed. > > Results: > > check_need_swap() - 50% major contributor to slowdown > ml_open() - 30% 2nd contributor > setfname() - 19% surprise, surprise > > The rest of functions are blazingly fast, take <1% of time. > Fast functions (negligible overhead) include: > - wipe_dummy_buffer() > - buf_copy_options() > - buflist_new() > - aucmd_prepbuf() > - aucmd_restbuf() > > I don't have real results for readfile() because I > tested on empty files. But on empty file readfile() works fast. If creating the swap file takes so much time, something strange is happening. Are you on a network filesystem perhaps? What system is this anyway?
Cygwin. But why swapfile is needed for read-only grepping ? Is it possible not to create swapfile for dummy buf ? To set readonly and nonmodifiable maybe, for dummy buffer ?
Testing with empty files may give a wrong impression. Try something
like:
:vimgrep notaword $VIMRUNTIME/**/*.vim
The .vim files are relatively small.
The remove the regexp code from the picture (search can easily be benchmarked separately from file loading), I used artificial temporary patch which allows to run N times, see attached patch and script.
I tried doing a bit of profiling, but it gets confused by the loops and reports bogus results.
Instead of profiling, I commented out lines in load_dummy_buffer() and rerun timing. This is how I saw how different parts affect executiorn time. Yakov
y
Description: Binary data
patch
Description: Binary data
