This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: svn speed traversing slow filesystems
On 11/25/05, Branko Čibej <brane@xbc.nu> wrote:
> Kaveh R. Ghazi wrote:
> > > On Sat, 2005-11-19 at 10:14 -0500, Kaveh R. Ghazi wrote:
> > > > Hi Dan,
> > > >
> > > > (BTW, sorry for the reposted messages.)
> > > >
> > > > While I was waiting for some svn commands to finish (cleanup,
> > > > update) on my solaris2.7 box, which has a slow filesystem, I
> > > > happened to run truss -p <svn-pid> out of curiosity to see what was
> > > > taking so long. Turns out that svn does many file operations on
> > > > long pathnames. I recall that gnu find and other gnu utilities that
> > > > do directory traversal got jumbo speedups by changing to the
> > > > directory and running the file ops on "./filename" without long path
> > > > prefixes.
> > > >
> > > > Could a future svn version get the same speedup?
> > >
> > > Actually, i just removed the need for most stat calls during update
> > > in 1.4.
> >
> > Thanks Dan, that's great, but for the remaining i/o calls, it really
> > does matter if you use long/paths/with/lots/of/slashes rather than
> > chdir and ./filenames instead. I believe other recursive gnu utils
> > besides gnufind like "rm -r" or "mkdir -p" etc were modified to use
> > the chdir mechanism also because the benefit was so great.
> >
> Yes that's fine, but we can't do this in SVN. We do the real work in
> libraries that are supposed to be thread-safe. The cwd is per-process on
> POSIX systems, as far as I know.
Yes, for this problem there may exist openat and friends. Of course you'd need
to check for the availability of them and provide a fallback.
Richard.