Process libtorrent alerts in a separate thread #468

New issue

Closed

opened 2026-02-21 15:07:31 -05:00 by deekerman · 4 comments

deekerman commented

2026-02-21 15:07:31 -05:00

Owner

Originally created by @sledgehammer999 on GitHub (Apr 8, 2013).

I think the qbtsession::readalerts() logic should be either

moved in a separate thread from the gui thread
or make qtimer that calls this method timeout(0). From the docs: timeout(0) makes it fire when the main loop doesn't have any gui events to process. So we could process 2-3 alerts and then exit the function in order to avoid freezing the gui too much.

Why is this an issue? Well even with 5 torrents running quite a lot of alerts are posted. Most of those alerts are ignored(ie piece/block request/finish, peer connections open/close, dht/utp stuff). So the while() spins quite a few times. Imagine that some users are reporting 300+ torrents in their sessions. And some of them notice lag in the UI update. With 300+ torrents the while() would have a lot of alerts to go through thus momentarily freezing the UI. Of course having ~10 running torrents isn't an issue.

@cdumez what are your thoughts on this? Should be marked for 3.1.x?

Originally created by @sledgehammer999 on GitHub (Apr 8, 2013). I think the qbtsession::readalerts() logic should be either 1. moved in a separate thread from the gui thread 2. or make qtimer that calls this method timeout(0). From the docs: timeout(0) makes it fire when the main loop doesn't have any gui events to process. So we could process 2-3 alerts and then exit the function in order to avoid freezing the gui too much. Why is this an issue? Well even with 5 torrents running quite a lot of alerts are posted. Most of those alerts are ignored(ie piece/block request/finish, peer connections open/close, dht/utp stuff). So the while() spins quite a few times. Imagine that some users are reporting 300+ torrents in their sessions. And some of them notice lag in the UI update. With 300+ torrents the while() would have a lot of alerts to go through thus momentarily freezing the UI. Of course having ~10 running torrents isn't an issue. @cdumez what are your thoughts on this? Should be marked for 3.1.x?

deekerman

2026-02-21 15:07:31 -05:00

closed this issue
added the
Performance
label

deekerman commented

2026-02-21 15:07:36 -05:00

Author

Owner

@cdumez commented on GitHub (Apr 8, 2013):

I'm away this week and I don't remember this part of the code very well. I'll try to take a look when I come back. Honestly, I have thought about moving libtorrent do a different process but this is more work :)

@cdumez commented on GitHub (Apr 8, 2013): I'm away this week and I don't remember this part of the code very well. I'll try to take a look when I come back. Honestly, I have thought about moving libtorrent do a different process but this is more work :)

deekerman commented

2026-02-21 15:07:36 -05:00

Author

Owner

@sledgehammer999 commented on GitHub (May 7, 2013):

I did some tests on various things. The bottleneck doesn't seem to be readalerts(). The bottleneck seems to be the repainting of the QTreeView. The custom delegate seems to be fast enough. The problem probably lies in the implementation of the QTreeView itself.

So moving this readalerts() logic in a separate thread shouldn't be a top priority. It would have minimum affect and possibly complicate code unnecessarily.

@sledgehammer999 commented on GitHub (May 7, 2013): I did some tests on various things. The bottleneck doesn't seem to be readalerts(). The bottleneck seems to be the repainting of the QTreeView. The custom delegate seems to be fast enough. The problem probably lies in the implementation of the QTreeView itself. So moving this readalerts() logic in a separate thread shouldn't be a top priority. It would have minimum affect and possibly complicate code unnecessarily.

deekerman commented

2026-02-21 15:07:36 -05:00

Author

Owner

@sorokin commented on GitHub (Jun 5, 2014):

@sledgehammer999 Probably this issue can be closed now as #1703 is merged.

@sorokin commented on GitHub (Jun 5, 2014): @sledgehammer999 Probably this issue can be closed now as #1703 is merged.

deekerman commented

2026-02-21 15:07:37 -05:00

Author

Owner

@sledgehammer999 commented on GitHub (Jun 5, 2014):