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.
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. .. 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). btw. what takes 12 minutes.. the entire repository? How many files? Tony