On 15/07/06, Bram Moolenaar <[EMAIL PROTECTED]> wrote:
Maciej Kalisiak wrote: > On 14/07/06, Bram Moolenaar <[EMAIL PROTECTED]> wrote: > > Please be specific about what kind of scanning needs to finish before it > > notices the typed key. All types of scans are implemented differently. > > Each should check for a typed key at regular intervals, but if there is > > one that doesn't I need to know which one to be able to look into that. > > OK, here's a more detailed rundown: > - default 'complete' is .,w,b,u,t,i > - when I hit ^N, I see, on the bottom line in Vim: > Scanning tags. (for about 5 seconds) > Scanning included file: C:\...\file1 > Scanning included file: C:\...\file2 > Scanning included file: C:\...\file3 (each of these included files: ~ 5s) > ... etc ... So these are all tags files? 5 seconds is a long time to scan a tags file. How big are they?
No, all the files (except the ./tags file in "Scanning tags.") are Python files, and so is the current file in which I hit ^N. They are all less than 1000 lines, and most are less than even 200 lines. But I've more or less resolved the issue while tweaking Vim on a different tangent. The culprit seems to have been too broad a 'path' variable. In particular, I've had "C:\Python24\Lib\**" in 'path', which is an understandably large subtree, with non-trivial depth and a lot of branching. Basically having a "foo\**" in path, where foo is any non-trivial directory, brings the whole thing to a crawl. The symptoms then are: the insert-completion takes very long to scan the tags file as well as any included files, and also, :checkpath becomes terribly slow, printing out a single line per second. I guess I was just asking too much of Vim. Now that I've trimmed down to a more modest 'path', things are going at decent speeds again, even the scanning of the tags file, incidentally. The thing I don't quite follow is that, I would expect a broader 'path' setting to merely result in a larger number of files to scan through in :checkpath or when looking for completions, but not necessarily affect the scanning time of a single particular file, which is what I was seeing...
