Skip to content

Performance: Avoid consecutive lock acquisitions in cache operations #285

Description

Summary

Multiple places in the codebase acquire the same mutex lock consecutively within a single logical operation, causing unnecessary lock/unlock overhead.

Affected Files

1. crates/pet-python-utils/src/cache.rs (lines 157-161)

self.symlinks.lock().unwrap().clear();
self.symlinks.lock().unwrap().append(&mut symlinks.clone());

Should be:

let mut locked_symlinks = self.symlinks.lock().unwrap();
locked_symlinks.clear();
locked_symlinks.append(&mut symlinks);

2. crates/pet-python-utils/src/cache.rs (lines 185-187)

self.symlinks.lock().unwrap().clear();
self.symlinks.lock().unwrap().append(&mut symlinks.clone());

3. crates/pet-pyenv/src/lib.rs (lines 51-52)

self.manager.lock().unwrap().take();
self.versions_dir.lock().unwrap().take();

(This one is acceptable since they're different mutexes)

4. crates/pet-poetry/src/lib.rs (lines 90-91)

self.poetry_executable.lock().unwrap().take();
self.search_result.lock().unwrap().take();

(This one is acceptable since they're different mutexes)

Impact

  • Reduces lock contention
  • Fewer atomic operations
  • Better performance in multi-threaded scenarios

Priority

High - Simple fix with measurable impact on lock contention.

Activity

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

Metadata

Metadata

Labels

debtCode quality issues

Type

No type

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions