[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: performance enhancement by working copy svn server

From: Ph. Marek <philipp.marek_at_bmlv.gv.at>
Date: Tue, 15 Apr 2008 15:25:08 +0200

On Dienstag, 15. April 2008, Harvey, Edward wrote:
> > I agree wholeheartedly with what John wrote in his reply. Scanning a
> > disk can be done a lot faster than we're currently doing; centralized
> > metadata helps, but there are obviously other tricks, too -- just as an
> > example, look at how quickly Google Picasa can scan your whole disk for
> > images!
> I challenge the idea that scanning the whole tree could possibly ever be
> "fast."
If seek time can be eliminated, by using a central data storage and going
through the inodes in "correct" order, you can save *much* time.

Ever tried FSVS? I'll quote my previous email; for 22147 (known) entries (ie.
that exist in the repository and are just checked for changes) on *cold*
        # time fsvs st > /dev/null
        real 0m6.000s
        user 0m0.240s
        sys 0m0.372s
Not bad, no?

That's on Linux, ext3.

> Yes, if you do it once and repeat it, then you're benefitting from
> the cache on the 2nd run - For my users that makes the difference between
> 10 minutes and 30 seconds. But they're only going to svn up (or whatever)
> ... once, twice, three times a day ...
How often do you do "svn st"?

> And the system is doing actual work
> in parallel. So they never benefit from the cache. Every time they scan
> the tree, it takes 10 minutes.
Well, if you always purge your OS's cache, you'll have to go to the harddisk
to get the information ...

> I considered seriously, writing a cron script to tar all the .svn dirs into
> /dev/null, and stat the whole working copy of every user, ever 5 minutes.
> Just to keep that info in cache. But I finally decided that was stupid
> enough to abandon it.
tar is "intelligent" enough to not bother with the data if it sees that it
writes to /dev/null - you'd have to use /dev/zero instead.

To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-04-15 15:45:38 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.