Skip to content

Performance: Avoid consecutive lock acquisitions in cache operations #285

@karthiknadig

Description

@karthiknadig

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.

Metadata

Metadata

Assignees

Labels

debtCode quality issues

Type

No type
No fields configured for issues without a type.

Projects

No projects

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions