getPeerCandidates() remake

[sadface]

Hi!

OProfile helped me (again) to find out that calling peerIsInUse() for each atom is expensive. But as maxCandidates value is previously known, we can sort atoms first and filter only a small subset of them later.

Despite sorting time and memory requirements are lightly increased, this patch saves around 10-15% cpu usage on my x86 linux machine downloading a single torrent with transmission-daemon --encryption-tolerated.

PS: Some debug message lost its original meaning. Sorry.

[sadface]

Hi,

Forget my last patch, please. It degrades seeding performance.

This new one does reduce cpu usage on both download and upload stages.
Changes:

• peerIsInUse() was moved to the lastest place of filtering chain. Thus we avoid calling this expensive function mainly on seeding stage.
• As the number of connection candidates may be known before calling getPeerCandidates(), we avoid running this expensive function when no candidates are required (result in 90% of calls saved when all torrent's peer slots are filled, common in popular torrents).

Sorry for my poor English.

[livings124]

Awesome work! I recommend opening ticket(s) on trac (http://trac.transmissionbt.com) for your patches so that we don't lose track. Thanks a lot!