perf: Reduce RwLock contention in summarization_worker.rs hot path
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 42/100
- Issue type
- Refactor
- Clarity
- Mostly clear
- Activity status
- Stale
- Tech stack
- rust
- Domain
- backend, performance
Research direction
Start with crates/terraphim_service/src/summarization_worker.rs at the listed lock acquisitions, then review the performance analysis from PR #429. Trace how status statistics are updated around JSON parsing and LLM calls, and measure the worker under load. Done means contention is reduced and throughput improves without losing the reported statistics.
Written by the indexing model from the issue text.
Description
Issue Description
Multiple RwLock acquisitions in the worker loop cause contention between workers updating stats.
Location
crates/terraphim_service/src/summarization_worker.rs (lines 239, 276, 311, 346, 376, 417, 433, 469, 503, 517)
Current Code
```rust
// Multiple lock acquisitions in hot path
{
let mut status = self.status.write().await;
status.total_processed += 1;
// ...
}
```
Impact
- CRITICAL priority - Performance
- Lock held during JSON parsing and LLM calls
- Blocks all workers during status updates
- 40-60% contention under load
Recommended Fix
```rust
use crossbeam::atomic::AtomicCell;
use std::sync::atomic::{AtomicU64, Ordering};
struct WorkerStats {
total_processed: AtomicU64,
total_successful: AtomicU64,
total_failed: AtomicU64,
total_cancelled: AtomicU64,
// Use separate lock for processing_times only
processing_times: Arc<Mutex<Vec>>,
}
impl WorkerStats {
fn record_success(&self, duration: Duration) {
self.total_processed.fetch_add(1, Ordering::Relaxed);
self.total_successful.fetch_add(1, Ordering::Relaxed);
// Only lock when updating times
let mut times = self.processing_times.lock().unwrap();
times.push(duration);
if times.len() > 100 {
times.remove(0);
}
}
}
```
Expected Improvement
- 40-60% reduction in lock contention under load
- Better parallelization
- Improved throughput
References
- Identified in performance analysis for PR #429
- Related to concurrent worker performance
- Dominant language
- Rust
- Stars
- 62
- Forks
- 5
- Avg merge
- 2h 27m
- Merged PRs (30d)
- 1
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from terraphim/terraphim-ai
-
Difficulty 5/5 Over a week Newbie friendliness 25/100
terraphim/terraphim-ai#885 ·
-
Difficulty 4/5 3-5 days Newbie friendliness 55/100
terraphim/terraphim-ai#871 ·
-
enhancement
Difficulty 5/5 Over a week Newbie friendliness 25/100
terraphim/terraphim-ai#810 · 2 comments ·
-
enhancement
Difficulty 5/5 Over a week Newbie friendliness 35/100
terraphim/terraphim-ai#729 ·
-
enhancement
Difficulty 5/5 Over a week Newbie friendliness 35/100
terraphim/terraphim-ai#728 ·
All issues in terraphim/terraphim-ai
Similar issues
-
risk:low runtime status:in-progress type:test
Difficulty 1/5 Under an hour Newbie friendliness 92/100
zeroclaw-labs/zeroclaw#11023 ·
-
good first issue refactor
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
EricSpencer00/Resilient#4835 · 1 comment ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
bisq-network/bisq-musig#204 ·
-
agent:ready documentation
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
cesarferreira/stax#890 ·