looks fine to me though fwiw I don't reproduce any performance delta on the "big" install that I have lying around.

if this is real: I wonder whether constraint parsing and version parsing would similarly benefit

if this is real: I wonder whether constraint parsing and version parsing would similarly benefit

Great idea. Although there is more variance in constraints and versions than in markers, it makes a significant difference, too.

I updated the times in the PR description. Further, I tested the change on another largish (non-public) project:

Cache info for private project:

CacheInfo(hits=66985, misses=78, maxsize=None, currsize=78) poetry.core.version.markers.parse_marker
CacheInfo(hits=452083, misses=739, maxsize=None, currsize=739) poetry.core.constraints.version.parser.parse_constraint
CacheInfo(hits=73960, misses=196, maxsize=None, currsize=196) poetry.core.constraints.generic.parser.parse_constraint
CacheInfo(hits=19933, misses=581, maxsize=None, currsize=580) poetry.core.version.pep440.parser.PEP440Parser.parse

The peak memory usage even decreased when caching constraints and versions.

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
1 Code Smell

No Coverage information
0.0% Duplication