TODO hardlink performance optimizations

jw schultz jw at
Wed Jan 7 08:06:26 GMT 2004

On Wed, Jan 07, 2004 at 01:33:43AM -0600, John Van Essen wrote:
> On Tue, 6 Jan 2004 22:33:06 -0800, Wayne Davison <wayned at> wrote:
> > 
> > I'd suggest also changing the last line of the function:
> > 
> > -        return file_compare(&f1, &f2);
> > +        return file_compare(f1p, f2p);
> > 
> > This is because the old way asks the compiler to take the address of f1
> > and f2, thus forcing them to become real stack variables.  Changing the
> > code to use the passed-in f1p and f2p allows the compiler to leave both
> > f1 and f2 as registers (if possible).
> Good point, but I have an even better suggestion, now that I
> finally understand the nuts and bolts of all the hlink.c code.
> The file_compare() is invoked when the dev and inode values match
> in order to present a consistent sorting order during the sort.
> There is no compelling reason to have the hlink list be sorted
> alphabetically.  It just has to sort consistently.  So the final
> comparison can be done on the addresses of the file_structs,
> since they are not moved around and will remain constant:
>         return ( ( f1 < f2 ) ? -1 : ( f1 > f2 ) );
> (Unsure if the code is right, but you get my drift.)
> For filesets with many hardlinks, this will use less CPU time.

There may well be good reason for having the link sets
subsorted consistantly with the file list.  See my notes
regarding COW, fork and the modification of the link info.

	J.W. Schultz            Pegasystems Technologies
	email address:		jw at

		Remember Cernan and Schmitt

More information about the rsync mailing list