getPeerCandidates() should be faster

[jordan]

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.

[jordan]

thinking-out-loud.. a few options:

1. build a subset of all candidates, based on the highest keys in getPeerCandidateScore()

2. 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)

3. 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.

[jordan]

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.

[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.