Custom Query (2447 matches)
Results (490 - 492 of 2447)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #2332 | WontFix | Speed optimizations to torrent.get_status | ||
| Description |
Optimized torrent.get_status by keeping track of if the torrent status has been updated since last call. If not, use the the previous values instead of calling the status functions. I've tested loading deluged with 1000 torrents and connecting thin client and leaving it running for 2 minutes. The number of calls to get_status is around 250000 Current get_status used a total of 15 seconds CPU, while this version used 6 seconds. According to cProfile the average runtime is reduced from 60 to 20 microseconds. The downside is that the code is a bit more verbose. https://github.com/bendikro/deluge/commits/develop-torrent-get-status-speedup |
|||
| #2379 | Fixed | Move cleanup of prev_status from torrent.py to torrentmanager.py | ||
| Description |
Each torrent instance has a LoopingCall that cleans up the prev_status dictionary regularly. With a lot of torrents the number of LoopingCalls starts to generate a lot of CPU usage. This patch replaces the LoopingCalls for each torrent with one LoopingCall in torrentmanager.py. I tested on my desktop copmuter with the daemon running idle (not downloading/seeding or with clients connected). With 5000 torrents the CPU usage was reduced from 26-40% to 3-5%. With 10000 it was reduced from 50-60% to 5-6%. |
|||
| #2406 | Fixed | Speed up adding multiple torrents | ||
| Description |
Adding large amounts of torrents is painfully slow because the torrents.state and torrents.fastresume files are written to disk after each torrent is added. This patch adds a new function to core which takes multiple torrents so that the state and fastresume files are only written to disk once. GTKUI add dialog uses this function. https://github.com/bendikro/deluge/tree/develop-add-torrents |
|||
