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 ...
Search found 3 matches
- Sun Nov 22, 2009 3:46 am
- Forum: Support
- Topic: getPeerCandidates() remake
- Replies: 2
- Views: 2557
- Fri Nov 20, 2009 6:39 pm
- Forum: Support
- Topic: getPeerCandidates() remake
- Replies: 2
- Views: 2557
getPeerCandidates() remake
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 ...
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 ...
- Thu Nov 19, 2009 12:09 am
- Forum: Support
- Topic: Too much system cpu usage
- Replies: 2
- Views: 2707
Too much system cpu usage
I noticed that symptom on my x86 linux machine running transmission-daemon.
OProfile and strace tools showed me the guilty: thousands of time() syscalls per second combined with a "slow" kernel high-resolution timer (ACPI PM timer). In these conditions every time() syscall wastes from 5 to 6 usecs ...
OProfile and strace tools showed me the guilty: thousands of time() syscalls per second combined with a "slow" kernel high-resolution timer (ACPI PM timer). In these conditions every time() syscall wastes from 5 to 6 usecs ...