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.

I've been profiling the daemon and I've created a patch that decreases the CPU usage of the daemon while clients are connected.

torrent.get_status

This method is called a lot of times! To speed this up I've restructured and split the code so that most of the calls that previously were to get_status now calls create_status_dict which simply creates a dict based on the cached info instead of asking libtorrent for a new status.

The internal dictionary used to create the dictionary with the status values is now created only once each for torrent instead of every time get_status is called.

The inner methods of get_status are moved out to avoid creating them for each call.

There are also changes to speed up frequent tests like has_metadata, and as few calls to libtorrent as possible.

core.get_torrents_status / libtorrent.post_torrent_updates

libtorrent.post_torrent_updates tells libtorrent to post an alert with the torrents that have changed since the last call to post_torrent_updates.

This is called from core.get_torrents_status when a client requests an updated status dict. If the statuses for the torrents were updated less than 2 seconds ago (the interval the GTKUI asks for updates), it will return a status dict created from the cached data instead of calling post_torrent_updates. This should make the daemon perform better with multiple clients connected.

Startup (loading torrents)

To speed this up I've added a variable wait_on_handler in alertmanager which is set just when the torrents are loaded. alertmanager will then call the handlers without waiting. This speeds up adding the torrents considerably (~40%).

Log statements (log.isEnabledFor)

Many of the log statements require "heavy" computations, so when summing together, the total time for the log statements is many seconds (roughly 5-10s on my desktop) when loading many torrents (I've tested with 2000).

Therefore I've added log.isEnabledFor on the most important log statements. When profiling startup of 2000 torrents, the log statements I've added log.isEnabledFor for used from 150ms to 600ms each (in total).

Redundant and unecessary RPC messages

I've removed some redundant RPC requests, and combined some to have less packets transmitted on startup.

• statusbar.py and systemtray.py:
  • Combined the requests for some config values into one RPC.
  • Removed calls to send_status_request on startup. These only result in two requests being sent almost at the same time.

• sessionproxy.py: Removed the call to self.get_torrents_status on startup. A few milliseconds after this request the torrentview requests the same data, resulting in the torrent list being transmitted twice when the GTK Client connects.

These changes reduces the CPU time of sessionproxy by a little more than 50%.

​https://github.com/bendikro/deluge/commits/master-sessionproxy-optimization