Attempt to exit early from _init if a job manifest exists and is valid.

[bdice]

Description

Many methods/properties of Job invoke a call to job.init(), including the first access to job.document and all accesses to job.stores and job.data.

This PR optimizes job.init() for jobs that are already initialized, by exiting early.

Motivation and Context

This is a performance enhancement for many common data access operations in signac.

Performance results for the script below:

Test	master	This branch (b4917d8)	Speedup
First init	3.426s	3.546s	0.966x (slower)
Already init'd	2.623s	1.774s	1.479x (faster)

import signac

project = signac.init_project('test')

for i in range(20000):
    project.open_job({'a': i, 'b': i*2, 'c': i*3}).init()

Types of Changes

• New feature

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 changelog and added all related issue and pull request numbers for future reference (if applicable). See example below.

[codecov]

Codecov Report

Merging #422 (f20ba30) into master (9db354f) will increase coverage by 0.02%.
The diff coverage is 50.00%.

@@            Coverage Diff             @@
##           master     #422      +/-   ##
==========================================
+ Coverage   76.48%   76.51%   +0.02%     
==========================================
  Files          45       45              
  Lines        7086     7086              
==========================================
+ Hits         5420     5422       +2     
+ Misses       1666     1664       -2     

Impacted Files	Coverage Δ
signac/contrib/job.py	92.80% <50.00%> (+0.79%)	⬆️

---

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 9db354f...f20ba30. Read the comment docs.

[csadorf]

I am actually wondering whether we should be specific here. Expected exceptions are OSError, what else?

[bdice]

_check_manifest can raise JobsCorruptedError, which is a subclass of RuntimeError. There may be other exception classes that are raised in that function (it uses json, hashlib, file reading/decoding). I am hesitant to specify the exception classes because I don't know how to be sure that we're providing sufficient exception coverage and the penalty is high. Not catching an exception would lead to broken behavior, because the job wouldn't actually be initialized at the end of the initialization method.

[csadorf]

But any of those very unexpected errors are something we should actually raise. We could very easily test which error classes to catch by simply running this against "no file", "corrupted file", "empty file", "binary file", and "permissions wrong", and that should be about it IMO. Catching "all" errors here means to effectively change the behavior of this function, does it not?

[bdice]

I would be fine with testing against those cases explicitly. However, I don't think the behavior of the function is changed by catching Exception here. From the previous behavior, I would say that the "finishing condition" of the initialization is that _check_manifest can complete without raising. I'm just testing that condition at the beginning as a way to exit early. Any errors in _check_manifest would be raised in the original behavior, when _check_manifest was called at the end.

[lyrivera]

LGTM!