Optimize Perforce revision parsing and file existence checks.
Review Request #8939 — Created May 11, 2017 and submitted
Perforce was doing a bit too much work when checking for the existence
of certain files and when parsing files at revision 1. For file
existence checking, we were using the default behavior of fetching the
complete contents of the file and using that to determine existence.
That wasn't the most optimal, especially for very large files. We now
usep4 fstat
to look up the file instead.For revision parsing, we had to work around some behavior in older
versions of Perforce where new files had a revision of 1 in the diff. To
determine whether the file existed in the repository, we ranp4 files
and checked the result. However, we weren't limiting the number of
results, and so files with a lot of history were slow. Also, for newer
versions of Perforce, revisions for new files are 0.Instead of running
p4 files
, we just use the new file existence
checks. This has the advantage of using/populating the existence cache,
helping reduce the number of remote calls even further. We also now only
run these tests if the revision is 1 (and we assume 0 means it's a new
file).
Unit tests pass.
Tested these with a real diff against a real server consisting of new
files at revision 0 and with files with large files containing lots of
history. Saw the results I expected, and reduced times needed for these
functions.