Measuring dependency resolution bottlenecks in Poetry

Poetry utilizes a SAT-solver based resolver to manage dependencies, but the time spent during poetry lock can vary significantly based on the state of the local cache and the breadth of version constraints in pyproject.toml.

When analyzing performance, it is necessary to distinguish between network-bound metadata retrieval and CPU-bound resolution logic. Because Poetry caches package metadata and wheels, initial cold-cache runs often mask the actual complexity of the dependency graph resolution.

Given these variables, what is the most reliable method to isolate the resolver's backtracking behavior from network latency? Which specific indicators in the verbose output (-vvv) confirm that a bottleneck is caused by overly broad version constraints rather than metadata fetching?