Cache find best candidate

[xavfernandez]

Cache find_best_candidate results

This is possible because self.make_candidate_evaluator only depends
on:

• the function arguments which are keys to the cache
• self._target_python which never changes during a pip resolution
• self._candidate_prefs which never changes during a pip resolution

On a fresh install, pip install <a package with ~ 100 dependencies>
runs on my machine in:

master (a0e34e9)

0m33.058s
0m34.105s
0m32.426s

This commit

0m15.860s
0m16.254s
0m15.910s

pip 20.2.4 - legacy resolver

0m15.145s
0m15.040s
0m15.152s

[McSinyx]

Does this mean that we can answer GH-8664 with We are there?

[uranusjr]

I’m a bit concerned this may cause some subtle bugs someday if we do change one of the instance variables and forgot to consider the cache. Would it be better to extract the logic into a pure function (outside of the class) and cache that instead?

[pradyunsg]

Ack. I agree w/ @uranusjr -- it'd be nice to make that a pure function (or a staticmethod on the same class) whose return value is cached. That'll ensure we're not caching function return values that are dependent on instance properties.

[xavfernandez]

Does this mean that we can answer GH-8664 with We are there?

For my use case, We are ^^

Would it be better to extract the logic into a pure function (outside of the class) and cache that instead?

I had the same concern, but those same concerns would also apply to 1dd6d56 :)
That doesn't mean we should not refactor this part to make it clearer but IMHO this should not prevent this from being merged (given the user impact).

[pradyunsg]

Alrighty, I'm OK to defer the cleanups to a follow up PR. :)

[pradyunsg]

Anyone wanna file tracking issues for the cleanup follow-up PRs?