[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Hideously slow VC status queries fixed

From: Eric S. Raymond
Subject: Re: Hideously slow VC status queries fixed
Date: Wed, 26 Dec 2007 21:19:40 -0500
User-agent: Mutt/1.5.15+20070412 (2007-04-11)

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>

reply via email to

[Prev in Thread] Current Thread [Next in Thread]