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 7:10 AM > To: evs at cvsnt.org > Subject: Re: [evs] Current status > > Kelly F. Hickel wrote: > > Then it should work as is. You could improve it by an unknown > > percentage by removing the list and just returning the highest candidate > > revision number. (or not, it's 90% faster as it is, so what's another > > few percent? ;> ) > > Well you're avoiding memory allocation, which is one of the slowest > operations... it'd be more than a few percent I'd expect. That's why I pointed it out, but it's a bit up in the air as the list nodes are cached, so there may not be any allocations. > > I assume you're just taking out the inneficiency of RCS_magicrev (which > could clearly work better the other way around - do the walklist and > have it return a candidate branch, then test for the physical revision.. > 99% of the time you'd only have to go through a single iteration). My Goal was to come up with the minimum change (to increase the likelihood of acceptance) that meant we didn't have to wait two hours to create a branch. If someone who understood rcs.c better than I, and was willing to make bigger sets of changes, took a good look at it, I'm sure it could be improved past the current 12 minute mark, probably down to the 7-8 minute range. 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. > > Tony > _______________________________________________ > evs mailing list > evs at cvsnt.org > http://www.cvsnt.org/cgi-bin/mailman/listinfo/evs -Kelly