[evs] Current status

Kelly F. Hickel kfh at mqsoftware.com
Mon Jan 15 02:39:58 GMT 2007


Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.



> -----Original Message-----
> From: evs-bounces at cvsnt.org [mailto:evs-bounces at cvsnt.org] On Behalf
Of
> Tony Hoyle
> Sent: Sunday, January 14, 2007 8:12 PM
> To: evs at cvsnt.org
> Subject: Re: [evs] Current status
> 
> Kelly F. Hickel wrote:
> > Note that with the patch disk IO is up considerably, percentage
wise, so
> > there's some lower limit where finding the rev faster isn't going to
> > help, compared to writing the tags in the files, but I'm sure we
aren't
> > there yet.
> 
> Someone came up with a patch that avoided this but I never applied it
-
> they preallocated lots of space in the RCS files then wrote the new
> patches directly into the existing file, avoiding the rewrite
entirely.
> 
> For their case where they were doing lots of tagging for builds etc.
it
> was quite a large speedup.  The downside (which unfortunately meant I
> never applied it) was you lost crash resilience - a badly timed crash
> could corrupt the tag data.
> 
> Finding the largest tag number *should* be an entirely in-memory
> operation, once RCS_parsercsfile is has been called (and it will be...
> theoretically you could optimise it out but it'd be a lot of work),
> since the version numbers and various bits of information are already
> cached.   You just have to iterate through the relevant ones and find
> the largest ones.

That's essentially what my patch is doing, it uses the RCS_parsercsfile
results that were being generated anyway.  It then iterates through
them.

> 
> .. or just forget about all that and have a 'largest tagid' written
into
> the RCS file header and increment it.  Then it's a single operation to
> read it and effectively zero time to calculate the new one.  I could
add
> that into evs in about 5 minutes if there was a measurable benefit
(TBH
> I'd prefer to get the numbers from a profiler first to find the
critical
> path).

Well, keeping it in the header would be much better (assuming you can
assure atomicity, which presumably you can).  But, it would have been a
much bigger deal and probably wouldn't be acceptable to the cvs
maintainers.  I did run cvs under Rational Quantify to determine that
this was the hotspot. I haven't bothered to run the patched version
because it's "fast enough" (at the moment).


> 
> btw. what takes 12 minutes.. the entire repository?  How many files?

The entire repo looks like around 72,224 files.  Some of the files have
over 2000 tags, half of which are branch tags. With both cvs branches
and both cvsnt versions (2.6 and the 3 beta) it took between 105 and 123
minutes to do a branch tag.  With my patch cvs 1.11 takes about 12
minutes, 1.12 is around 11 minutes 15 seconds.

-Kelly

> 
> Tony
> _______________________________________________
> evs mailing list
> evs at cvsnt.org
> http://www.cvsnt.org/cgi-bin/mailman/listinfo/evs


More information about the evs mailing list