Re: Hideously slow VC status queries fixed

[Eric S. Raymond]

Tom Tromey <address@hidden>:
> Eric> It gives me great pleasure to be able to announce that I have found,
> Eric> and fixed, the bug that made C-x v d so godawful much slower than the
> Eric> underlying commands.
> 
> Nice.  The speed of vc-dired is one reason I'm still using pcl-cvs
> (and the un-bundled psvn) for everything.
> 
> I optimistically tried the new vc-dired on my killer test case: gcc.
> I didn't try the whole trunk (since that is just way too big), but I
> tried on 'trunk/gcc' -- unlike running on the whole trunk, this is a
> reasonable thing to want to do since most hacking takes place here.
> 
> After a few minutes I got this:
> 
>     Warning (undo): Buffer `gcc' undo info was 3023389 bytes long.
>     The undo info was discarded because it exceeded `undo-outer-limit'.

Yeah.  What's clearly happening there is that it's generating a
*monstar* status listing recursing down all those directories.  The
resulting output is big enough to strain Emacs's innards.  There ain't
much I, as a mode author, can do about that.
 
> I don't know whether vc-dired is expected to scale to a working
> directory with 26,499 files underneath it.  I sure wish it would :-).

vc-dired will scale as well as Emacs scales (he said, a bit evasively.)

I don't think the bottlneck is VC anymore.  In the normal cases (CVS, 
SVN, Mercurial), VC now generates just one (1) command.  I suppose
parsing time could be an issue -- has anyone profiled 26,499 regexp
matches lately ?

I know this: C-x v l is now *fast* on normal-sized SVN, CVS, and Mercurial
directories.   It sure wasn't before.
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>