developer: add a configuration for turning lru_caching off

[oliver-sanders]

In order to perform memory profiling for Cylc it is generally necessary to disable the lru_cache mechanism that we use to speedup datetime / recurrence operations.

Let's make this configurable via an environment variable rather than performing this hack every time.

Check List

• I have read CONTRIBUTING.md and added my name as a Code Contributor.
• Contains logically grouped changes (else tidy your branch by rebase).
• Does not contain off-topic changes (use other PRs for other changes).
• Applied any dependency changes to both setup.cfg (and conda-environment.yml if present).
• Tests are included (or explain why tests are not needed).
• Changelog entry included if this is a change that can affect users
• Cylc-Doc pull request opened if required at cylc/cylc-doc/pull/XXXX.
• If this is a bug fix, PR should be raised against the relevant ?.?.x branch.

[ChrisPaulBennett]

LGTM

[ChrisPaulBennett]

I closed and reopened the PR to hopefully clear the macOS test that is failing

[oliver-sanders]

Tests happy.

Coverage complaining about pre-existing coverage holes.

[wxtim]

Suggested change

	# perforance. For profiling, this can be disabled by setting the environment
	# performance. For profiling, this can be disabled by setting the environment

[wxtim]

It's fine as far as it goes. Do you want to consider these other cases (there aren't many):

cylc/flow/host_select.py:516:@lru_cache()
cylc/flow/host_select.py-517-def _tuple_factory(name, params):
--
cylc/flow/scheduler_cli.py:313:@lru_cache()
cylc/flow/scheduler_cli.py-314-def get_option_parser(add_std_opts: bool = False) -> COP:
--
cylc/flow/util.py:215:@lru_cache(maxsize=100)
cylc/flow/util.py-216-def _serialise_set(flow_nums: tuple) -> str:
--
cylc/flow/util.py:220:@lru_cache(maxsize=100)
cylc/flow/util.py-221-def deserialise_set(flow_num_str: str) -> set:

[wxtim]

Approved.

[oliver-sanders]

It's fine as far as it goes. Do you want to consider these other cases (there aren't many):

I went with "no" on those:

• Small cache size.
• Small object size.
• Unlikely to ever accumulate (flow usage non-existent, host-select only performed on startup).