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 firstname.lastname@example.org.
> -----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