On 11/25/05, Branko Čibej <[EMAIL PROTECTED]> 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.
