Re: cvs-fast-export on NetBSD repo, first results (was Re: Why I'm working on a NetBSD conversion)

["Eric S. Raymond" <esr%thyrsus.com@localhost>]

Jeff Rizzo <riz%NetBSD.org@localhost>:
> >That is *astonishingly* slow.  So far I have seen full benchmarks
> >on three systems, and the times cluster around 5 hours. I think
> >we first need to figure out why your runs are taking seven times
> >longer.
> 
> Now I'm concerned - I don't see any particular reason why my
> hardware should be so much slower than other stuff described, unless
> there's differences in either the OS services used by the code, or
> unless (heaven forbid) there's something inherently slower in
> NetBSD.  I wish I had time to try a different OS on that hardware to
> see, but that's not likely to happen.

I have a run going now to check the time with the latest speedups, but I'm
not expecting results for two hours yet.

> >3. On all theree NetBSD runs I've seen, compute time for the branch
> >    merge dominated the runtime.  So faster single-thread performance
> >    of the hardware matters a lot.
> >
> >4. Cache width matters a lot too because the working set is so big.
> 
> OK, I'll see what I can find.  For obvious reasons, I'm interested
> in doing a conversion of this nature on NetBSD.  :)

Indeed. :-)

> >One of my development partners just turned in a patch that cuts
> >conversion time on my largest benchmark repo (which happens to
> >be historical Emacs CVS) by 20%. I'll run some tests and report.
> 
> I'd love to see it when it hits the cvs-fast-export git tree.

It's already there - Laurewnce Hygate's memoized-sort patch.

> (Incidentally - I notice from the previous version of
> cvs-fast-export I built (1.15 or so) that GNU make now seems to be a
> silent dependency)

I'm open to fixing that if you can tell me what the specific problem.
-- 
		<a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>