vimgrep fastest

[epanda]

Hello,

Is there someone here who think that vimgrep is not enough fast.

Visual Studio search tool is faster than vimgrep but why ?

Can we have a tool as fast as Visual Studio search tool ?

Thanks for your response.
epanda

[Tim Chase]

> Is there someone here who think that vimgrep is not enough fast.
>
> Visual Studio search tool is faster than vimgrep but why ?
>
> Can we have a tool as fast as Visual Studio search tool ?

I'm not sure what you're comparing here. vimgrep offers the
flexibility of Vim's full regexp parsing engine. Last I tried
VS, it's regexps were anemic at best. So if all you need is
simple string searching, you may be interested in things like
ctags which index specified files and allow for rapid jumping.

However, if you need the power of vim's regexp engine, AFAIK, you
simply *can't* get that in VS.

There are also a lot of other variables to consider...

What OS? (I find Vim on Linux to have better filesystem response
than Vim on Win32...mostly due to the underlying filesystem types
and caching)

What app is responsible for keeping any search-result cache
up-to-date? How frequently is such a cache updated? How
detailed is the cache (can you exploit it for arbitrary regexps
or does it only help for fixed strings, or even just fixed "words")?

If all you're looking for is fixed text, your OS search
functionality is likely your best bet. Just use Spotlight (Mac);
Beagle, Tracker, Recoll (Linux); Windows Search (Win32); or
Google Desktop Search (which is rumored to run on multiple
platforms).

Please include your usage pattern and timing results on the same
hardware so it's easier to help you.

-tim

[ThoML]

> I'm not sure what you're comparing here. vimgrep offers the
> flexibility of Vim's full regexp parsing engine.

Well, vimgrep really isn't exactly lightning fast. If I'm not
mistaken, one reason for this is that vim loads every file in a
buffer. This also means that autocommands are evaluated -- I just got
an error.

I ran a few tests (~5MB, 570 files), just searching for "test":

grep: 0.6s
glark: 3.8s
vimgrep: 30s
trag: 20s

searching for "t[aeiou]st" (just to make sure we use regexp):
grep: 1s
glark: 4.1s
vimgrep: 30s
trag: 29s

grep & glark (ruby-based) ran on cygwin bash/rxvt.
trag is a vim-only plugin.

vimgrep is the most convenient solution of course.

Regards,
Thomas.

[epanda]

I am on a windows OS and I prefer vimgrep than a VS search tool.

My project has about 450 files and I have done a test with a friend ho
was working with VS to to a simple search of include file.

VS find the four files in 3-4 seconds
Vimgrep in more than 20-30 seconds....I was afraid.

I know ctags and use them but it has the inconvenient that you must
refresh database file.



I am a pro unix vim but I just note that vimgrep do the things in 30
seconds.
I am worry now

[Yegappan Lakshmanan]

Hi,

On Sun, Feb 24, 2008 at 10:16 AM, epanda <callin...@hotmail.fr> wrote:
>
> I am on a windows OS and I prefer vimgrep than a VS search tool.
>
> My project has about 450 files and I have done a test with a friend ho
> was working with VS to to a simple search of include file.
>
> VS find the four files in 3-4 seconds
> Vimgrep in more than 20-30 seconds....I was afraid.
>
> I know ctags and use them but it has the inconvenient that you must
> refresh database file.
>
> I am a pro unix vim but I just note that vimgrep do the things in 30
> seconds.
> I am worry now
>

You can use the several grep utilities available in the GNU grep package
or you can use the MS-Windows findstr utility to search for patterns
across multiple files and directories quickly.

The following Vim plugins integrate these utilities with Vim:

http://vim.sourceforge.net/scripts/script.php?script_id=311
http://vim.sourceforge.net/scripts/script.php?script_id=1575

- Yegappan

[Benjamin Fritz]

Is there some way to disable autocommadns automatically whenever you
perform a :vimgrep, and re-enable them afterwards? This seems like a
good way to speed things up significantly, since (from what I
understand) Vim loads each file into memory normally in order to
search it. There may be some unforseen problems I suppose.

I guess I could just create a command called Vimgrep that does this,
and passes all arguments on to :vimgrep, but that sort of thing seems
like it would be fairly annoying.

[A.Politz]

Benjamin Fritz wrote:

>>
>>
>> >
>> > VS find the four files in 3-4 seconds
>> > Vimgrep in more than 20-30 seconds....I was afraid.
>> >
>>
>>
>>
>>
>>
>

>Is there some way to disable autocommadns automatically whenever you
>perform a :vimgrep, and re-enable them afterwards?
>
>
>

Filetype autocommands are disabled when vimgrepping.
The problem/cause might be found in the win32 code,
at least on my linux system I get reasonable performance
( ~500 files,~ 5Mb, ~5 sec ).

-ap

--
:wq

[Charles E Campbell Jr]

Benjamin Fritz wrote:

>
>Is there some way to disable autocommadns automatically whenever you
>perform a :vimgrep, and re-enable them afterwards? This seems like a
>good way to speed things up significantly, since (from what I
>understand) Vim loads each file into memory normally in order to
>search it. There may be some unforseen problems I suppose.
>
>I guess I could just create a command called Vimgrep that does this,
>and passes all arguments on to :vimgrep, but that sort of thing seems
>like it would be fairly annoying.
>
>
>

Well, the Vimgrep solution allows one to avoid any events; certainly
vimgrep has no such options. Perhaps

com! -nargs=* Vimgrep let s:eikeep=&ei|set ei=all|vimgrep <args>|let
&ei=s:eikeep|unlet s:eikeep

will do it.

Regards,
Chip Campbell

[epanda]

Charles,

Can you explain to me the goal of each option ?

Vimgrep will be faster with those options ?

Thanks
Best Regards
Nico


On 25 fév, 20:52, Charles E Campbell Jr <drc...@campbellfamily.biz>
wrote:

[Charles E Campbell Jr]

epanda wrote:
> Charles,
>
> Can you explain to me the goal of each option ?
>
> Vimgrep will be faster with those options ?
>

No guarantees -- but feel free to try it. There's only one option: ei
(:help 'ei' for full details). By setting ei=all, all events are
ignored, including syntax highlighting, autocmds, etc. The bit I sent
copies your current setting of ei, sets ei=all, then restores ei after
doing a vimgrep.

Regards,
Chip Campbell

[Eric Tetz]

On Sat, Feb 23, 2008 at 8:53 AM, ThoML <mica...@gmail.com> wrote:
> grep: 0.6s
> glark: 3.8s
> vimgrep: 30s
> trag: 20s

On Mon, Feb 25, 2008 at 11:45 AM, A.Politz <pol...@fh-trier.de> wrote:
> The problem/cause might be found in the win32 code,
> at least on my linux system I get reasonable performance
> ( ~500 files,~ 5Mb, ~5 sec ).

It *might* have something to do with file globbing. It starts out slow
and seems to scale up exponentially:

http://mail.google.com/mail/#label/vim/11819be8d402f8bf

I haven't done any testing to see if that's related to your problem,
but I thought I'd throw it out there. I'm pretty sure vimgrep calls
the same globbing routine that args does (dos_expandpath), so it would
suffer from the same scaling issue.

Cheers,
Eric

[Hari Krishna Dara]

One issue I normally notice with disabling all events and going through
buffers (at least when :bufdo is used) is that when you visit these
buffers later they appear without any syntax highlighting, so you have
to an :e to trigger fresh autoload events and get filetype detected.

--
Thanks,
Hari
>
> Regards,
> Chip Campbell
>
>
> >
>

[ThoML]

> No guarantees -- but feel free to try it.

Cool. My test run now takes 2s with vimgrep.

I took a look at the sources. It seems the intention for running
certain autocommands was to ensure the right encoding is being used.
This advantage of vimgrep over pure grep will be lost when setting ei
to all, I suppose. And one has to reload the file as Hari has said.

Regards,
Thomas.

[Charles E Campbell Jr]

You could probably set up a BufEnter autocmd to do the reload (and have
it remove itself), and embed it in the original command.

Regards,
Chip Campbell

[ThoML]

> You could probably set up a BufEnter autocmd to do the reload (and have
> it remove itself), and embed it in the original command.

I currently run vimgrep with the j flag and then use :cnext which
currently seems to work fine.

Regards,
Thomas.

[Tony Mechelynck]

Charles E Campbell Jr wrote:

Or maybe you could run ":vimgrep" with ei=all, then set ei= and reload (only)
the file containing the first match if it hasn't got syntax highlights.
Ulterior uses of ":cnext" ":cnf" ext. ought to trigger FileType, Syntax, and
other autocommands.

Best regards,
Tony.
--
An Army travels on her stomach.

[epanda]

As Eric Tetz says, with option set ei=all, vimgrep takes a long time
to load all buffers and in a second time, search goes quickly.

But with 30 Mo about 450 files (about 2000 lines per files) , my
vimgrep with option ei=all always takes more than 10 seconds.

It's hard to lose against Visual Studio. Arg... hi hi
:)



On 26 fév, 18:39, Tony Mechelynck <antoine.mechely...@gmail.com>
wrote: