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.
---------------------------------------------------------------------
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:16:43 CEST