Skip to content

Profile Poetry identification and avoid whole-inventory cloning with an alias index #537

Description

Tracking plan: #528
Priority: P3, measurement-gated optimization. Evidence: cloning/linear scan confirmed; end-user latency impact not yet profiled.

Problem

Poetry's cached discovery lookup clones the complete LocatorResult, including all environments, and try_from then scans that result and its symlinks for each candidate. At larger inventories this can produce repeated whole-inventory allocation and candidate-by-environment work. Cold concurrent callers can also repeat cache population work.

Sources: find_with_cache, try_from.

Scope

First measure identification and allocation/operation counts over representative Poetry inventory sizes using deterministic fixtures. If material, share immutable discovery results and index executables/aliases for direct lookup. Reuse existing per-key single-flight machinery where appropriate instead of adding another cache framework.

Preserve Poetry-versus-generic-venv precedence, prefix/project/manager fidelity, platform path semantics, and the full/workspace/kind-filtered refresh-state merge contract. Do not introduce broad cross-refresh cache persistence without an invalidation design.

Acceptance criteria

  • The issue records before/after operation or allocation counts and timings across multiple inventory sizes; any optimization claim is tied to evidence.
  • If indexing is justified, repeated identification no longer clones/scans the entire inventory for each candidate.
  • Alias/case/symlink identity, workspace association, manager details, refresh merging, and configuration invalidation have behavior tests.
  • Concurrent cache misses avoid unnecessary duplicate work without deadlocking or permanently caching failures.
  • Small-inventory latency and memory do not materially regress under Gate client-observed refresh latency and define accurate first-environment timing #531/Benchmark long-lived PET sessions, real concurrent resolves, and inventory scaling #533.
  • If the measured benefit is negligible, close with measurements and a documented deferral instead of landing complexity solely to remove clones.

Dependencies

Depends on #533 for scale fixtures and #536 for stable cache/snapshot ownership. This is deliberately after the reproduced process/transport failures; do not treat it as the first performance fix.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions