Changed Project __contains__ method to run in constant time.

[bdice]

Description

I was running a cheap operation on a large data space (50k statepoints) with python project.py run. I noticed there was a very large initialization time before the operations began. I hit Ctrl+C a few times and identified that the __contains__ check was taking time proportional to O(N_jobs).

The specific code path being triggered was:

1. FlowProject.run calls the select filter over pending operations:
   https://github.com/glotzerlab/signac-flow/blob/c4d84fecaa18cd7556be85090e4332482bd79d38/flow/project.py#L1692

2. The select filter checks if job not in self:
   https://github.com/glotzerlab/signac-flow/blob/c4d84fecaa18cd7556be85090e4332482bd79d38/flow/project.py#L1650

3. The __contains__ method calls self._find_job_ids() with no arguments:
   

   signac/signac/contrib/project.py

   Line 411 in 48e3158

   return job.get_id() in self._find_job_ids()

4. The _find_job_ids() function returns a list of self._job_dirs() immediately:
   

   signac/signac/contrib/project.py

   Lines 524 to 526 in 48e3158

   	def _find_job_ids(self, filter=None, doc_filter=None, index=None):
   	if filter is None and doc_filter is None and index is None:
   	return list(self._job_dirs())

5. _job_dirs() iterates over all the subdirectories in self._wd, checking each of them against the regular expression JOB_ID_REGEX before yielding.
   

   signac/signac/contrib/project.py

   Lines 374 to 376 in 48e3158

   	for d in os.listdir(self._wd):
   	if JOB_ID_REGEX.match(d):
   	yield d

6. Finally, job.get_id() is checked against the list of all job ids returned by _job_dirs().

In my understanding, this should be equivalent to a constant-time check like the one I proposed in this PR. The regular expression validation is not necessary because we're getting the job id directly from the Job object itself, and we really just need to know if that id string is a subfolder of self.wd.

Motivation and Context

Before implementing this change, the select filter was running at ~300 iterations per second. After, it ran the select filter almost immediately (couldn't time it effectively, but there were 45,000 jobs so it's about 100x faster for this size of data space).

Existing tests pass, and I welcome suggestions for additional tests if this might introduce any unexpected behavior.

Types of Changes

• Documentation update
• Bug fix
• New feature
• Performance enhancement 🐎 🚗
• Breaking change¹

¹The change breaks (or has the potential to break) existing functionality.

Checklist:

• I am familiar with the Contributing Guidelines.
• I agree with the terms of the Contributor Agreement.
• My name is on the list of contributors.
• My code follows the code style guideline of this project.
• The changes introduced by this pull request are covered by existing or newly introduced tests.

If necessary:

• I have updated the API documentation as part of the package doc-strings.
• I have created a separate pull request to update the framework documentation on signac-docs and linked it here.
• I have updated the changelog.

[bdice]

@vyasr I added you as a reviewer since the Pull Assigner wasn't working. I would like your input on whether this is a "safe change" with respect to signac's data model, before I go further with this PR.

[bdice]

Offline discussion with @vyasr: This is probably an ok change but it makes our implementation more concrete and less abstract. I'm perfectly fine with that (in light of our potential rewrites for a more flexible storage engine in signac v2.0) because it's reasonable to expect that other potential backends should be able to implement their own __contains__ check in O(1), without relying on generic O(N) methods.

@csadorf If you'd like to weigh in, feel free. Otherwise we'll plan on merging this ~3 days after @vyasr reviews.

[csadorf]

LGTM.

[vyasr]

This must be merged after #232.

[codecov]

Codecov Report

Merging #231 into master will increase coverage by 0.07%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master     #231      +/-   ##
==========================================
+ Coverage   64.77%   64.84%   +0.07%     
==========================================
  Files          39       39              
  Lines        5558     5558              
==========================================
+ Hits         3600     3604       +4     
+ Misses       1958     1954       -4

Impacted Files	Coverage Δ
signac/contrib/project.py	90.81% <100%> (ø)	⬆️
signac/contrib/import_export.py	84.73% <0%> (+0.26%)	⬆️
signac/contrib/collection.py	89.15% <0%> (+0.56%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update b3d06ef...43fa451. Read the comment docs.