#3957 closed Enhancement (fixed)
getPeerCandidates() should be faster
Reported by: | jordan | Owned by: | jordan |
---|---|---|---|
Priority: | Normal | Milestone: | 2.30 |
Component: | libtransmission | Version: | 2.13 |
Severity: | Normal | Keywords: | |
Cc: |
Description
I'm not sure about the best way to do this, but getPeerCandidates() and its subfunctions all show up pretty high in perf measurements. If we can be smarter about building this array, we should do so.
Change History (3)
comment:1 Changed 10 years ago by jordan
comment:2 Changed 10 years ago by jordan
- Milestone changed from None Set to 2.30
- Resolution set to fixed
- Status changed from new to closed
This is no longer an issue as of r12253 and r12254... getPeerCandidates() is no longer a significant factor in my profiling.
getPeerCandidates() itself hasn't changed significantly, but since we've shrunk the pool of peers by getting better at pruning bad peers, the slow getPeerCandidates() symptom has been fixed anyway.
comment:3 Changed 10 years ago by gunzip
just thought to add comment about r12253 and private trackers...
this is related to ticket #4158, which i filed a bit ago concerning scrapes that were reported "successful" but incorrectly returned "0 seeders and 0 leechers". this turned out to be more of an issue as r12253 now causes all peers i'm uploading to to be instantly shed. gradually the peers are re-acquired but nevertheless this keeps re-occurring on each scrape interval, slowing down overall performance.
since r12253, i've been applying my own patch to remove those 2 lines otherwise the private tracker i use is constantly dropping peers. don't know how common this is or if other private trackers have this same quirk, but wonder if r12253 could be reverted in the builds to prevent future bug reports.
thinking-out-loud.. a few options: