p4 obliterate prior to 2005.1 is Slow

Why is "p4 obliterate" so slow on my pre-2005.1 Perforce server?

PROBLEM

Why is p4 obliterate so slow before 2005.1?  Is there any way I can make it go faster without upgrading my Perforce server?

SOLUTION

Obliterate is slow because it scans the entire revisions table looking for evidences of "lazy copies" that need to be undone, and it scans the entire client/label "have" list for references to the file.

During branching and integration, Perforce sometimes does a "lazy copy" of a source file, meaning that rather than checking in a new revision of a file it simply sticks in a pointer to the original file, since the text would be the same. If you obliterate the original file, Perforce must first find any files that are lazy copies of that file and do a physical copy. Because of the way the metadata is keyed in server versions prior to 2005.1, there is no quick way to find all the pointers to a particular file. Instead, Perforce must scan the entire "revisions" table looking for the pointers.

Also due to the keying of the metadata, there is no quick way to find what clients or labels have a given file, and so each and every label and client must be searched for references to the file.

In sum, the bulk of the database must be scanned for obliterate to work, even if you obliterate a single file.

Obliterate does its scan once per file argument, and so if you are obliterating multiple files, you can speed things up by minimizing the number of arguments. One way is to use a Perforce wildcard, e.g. "p4 obliterate //depot/this/stuff/..." rather than naming each file. A second way, where the files to be obliterated can't easily be captured as a single wildcarded name, is to create a new client whose view includes only the files to be obliterated -- for example:

View:

	//depot/file1 //tmpclient/file1
	//depot/there/file2 //tmpclient/file2
	//depot/over/here/file3 //tmpclient/file3

Then perform the obliterate using the temporary client spec:

p4 obliterate //tmpclient/...

It will still scan the whole database, but only once.

Note:
As of server version 2005.1, obliterate does much more limited scans (due to lazy copy indexing), so clumping obliterates into single-argument invocations is no longer needed.