On Wed, Apr 16, 2008 at 10:16 PM, Benjamin Smith-Mannschott
<bsmith.occs_at_gmail.com> wrote:
>
> On Apr 16, 2008, at 19:12, David Glasser wrote:
> ... snip...
>
> > > I'm convinced that a disk scan can be made orders of magnitude
> > > faster than ours is now, even without FS-specific tricks (like,
> > > e.g., walking the $MFT on NTFS)
> > >
> > > Agreed.
> > > Isn't Mercurial, with their revlog format, an example of
> > > an implementation which demonstrates this ability to be much
> > > faster for these type of operations.
> >
> > Totally unrelated.
>
> How so?
>
> This representation seems to be designed *specifically* to account for
> the essentially sequential nature of disk access. (i.e. random access
> is not cheap.)
>
> http://www.selenic.com/mercurial/wiki/index.cgi/Revlog
> > With one read of the index to fetch the record and then one read
> > of the revlog, Mercurial can reconstruct any version of a file
> > in time proportional to the file size.
> ...snip...
> > So that adding a new version requires only O(1) seeks, the
> > revlogs and their indices are append-only.
>
> http://hgbook.red-bean.com/hgbookch4.html#x8-870004.5.4
> > 4.5.4 Avoiding seeks
> >
> > Critical to Mercurial's performance is the avoidance of seeks of the
> > disk head, since any seek is far more expensive than even a
> > comparatively large read operation.
> ...snip...
>
> It seems to me that Mercurial to compensate for the performance issues
> that SVN's working copy format so successfully demonstrates.
Yes, the revlog format is designed to deal with the performance issues
of stitching together a bunch of deltas with as few seeks as possible.
This is similar to issues that Subversion faces on the server.
It has nothing to do with efficiently locating changed files in the
user's working tree.
--dave
--
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
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-17 07:48:30 CEST