Opened 11 years ago

Closed 10 years ago

Last modified 10 years ago

#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:


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 11 years ago by jordan

thinking-out-loud.. a few options:

  1. build a subset of all candidates, based on the highest keys in getPeerCandidateScore()
  1. keep the list of candidates for a short period, instead of rebuilding it every time. (And, invalidate the list when torrents are added, removed, stopped, or started)
  1. rather than using one big pool of peers, sort the torrents instead, and then work through each torrent one-by-one, sorting and trying out its smaller pool of peers before moving on to the next torrent.

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.

Note: See TracTickets for help on using tickets.