Opened 11 years ago

Closed 11 years ago

Last modified 6 years ago

#2255 closed patch (Fixed)

Speed optimizations to the daemon

Reported by: bro Owned by:
Priority: minor Milestone: 2.0.0
Component: Core Version: master
Keywords: Cc:


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


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.

  • and
    • 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.
  • 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.

Change History (6)

comment:1 Changed 11 years ago by bro

This patch is not "commitable" as it contains some comments here and there. I'd appreciate some feedback on the changes and maybe if there are other things to do, or if some things could be done differently.

comment:3 Changed 11 years ago by gazpachoking

  • Resolution set to fixed
  • Status changed from new to closed

Merged in 8c106ce8c

comment:4 Changed 11 years ago by Cas

  • Milestone changed from performance to 1.4.0

comment:5 Changed 9 years ago by Cas

  • Milestone changed from 2.0.x to 2.0

comment:6 Changed 6 years ago by Cas

  • Milestone changed from 2.0 to 2.0.0

Milestone renamed

Note: See TracTickets for help on using tickets.