Custom Query (2447 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (526 - 528 of 2447)

Ticket Resolution Summary Owner Reporter
#3093 WontFix Speed regulation ignored. loput
Description

When download speed limit is set to be more than about 4100KB/s, it gets completely ignored and speed is maxed out. Even after setting it back to 4100, it's ignored until deluge is restarted.

Client: 1.3.15

libtorrent: 1.1.4.0

Linux 4.11.9-1-ARCH #1 SMP PREEMPT x86_64

#2332 WontFix Speed optimizations to torrent.get_status Bro
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

#2184 Fixed Speed optimizations to the torrentview in GTKUI Bro
Description

With many torrents (hundreds), the GTKUI torrent view gets noticeably slower and slower. With around 1800 torrents, each call to update_view takes around 400-600ms on my machine, when showing all the torrents. This causes the entire thing to freeze until it's finished updating.

I've optimized the update_view method so that now, each update takes around 15-20ms when showing all torrents with sorting on the Name column, and a little less with no sorting. CPU usage when showing the All list is down from 90-100% to 4-10%

It's still quite slow to change list, e.g. from a small list (say "Downloading" with a couple of torrents), to "All" with 1800 torrents. This takes about 350-400ms on my machine.

Thats because it has to do this for most of the torrents:

row[filter_column] = True

Also loading the list when first connecting was crazy slow because of a very inefficient way of adding the rows to the liststore. Adding the rows is now down from about 3 seconds to 20-30ms.

The two most important changes for the speed increase is:

  • Test for the value row[filter_column] before setting a new value.
 if row[filter_column] is True:
   row[filter_column] = False
 if row[filter_column] is False:
   row[filter_column] = True

  • The first try/catch in the for-loop (for row in self.liststore)

Since most updates are of the same list, we now expect the torrent_id to be in the status dictionary, instead of first checking if it is.

Optimized update_view and add_rows on 1-3-stable: https://github.com/bendikro/deluge/commit/762ad783e2b4d22c74955ddd0bbe86fc13d8550f

If anyones interested, a version with time tests and prints is in the branch 1.3-dev-torrentview_time_test.

Batch Modify
Note: See TracBatchModify for help on using batch modify.
Note: See TracQuery for help on using queries.