-
-
Notifications
You must be signed in to change notification settings - Fork 210
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Speed up delegating by returning multiple request assignments at once #250
base: master
Are you sure you want to change the base?
Conversation
Thanks so much for this new code @kannibalox! Would you mind submitting this to the develop branch on my new rTorrent project? I would like to distribute this change to multiple platforms. You'll know about in about 2 minutes if the change builds successfully with LTO. There are GitHub action runners waiting for you! I will test the change for you to ensure it works properly. |
Unfortunately I already develop against vanilla while porting changes into jesec/rtorrent for personal use, and for the sake of my own sanity I can't add in support for a fork I'm not using. |
This is totally understandable. I will backport these changes to my fork, like I did for your simplified queue entries. If you change your mind and would like to use stickz/rtorrent in the future, I'll have most of the jesec/rtorrent changes back ported as well. I was able to greatly improve the UDNS implementation with your simplified queue entries! |
From Kannibalox: rakshasa/libtorrent#250 In addition to the main change, this also makes some other performance improvements: Modifies Block::insert to return a NULL if the peer already exists, to avoid needing to scanning for the peer info twice. BlockList uses a regular std::vector with the copy assignment/constructor disabled
@kannibalox This change crashes the torrent client near the end of a download. I have a limited stack trace, pointing to the newly revised function
|
Should be fixed now @stickz, let this be a lesson to me that no final little change is too small to thoroughly test. |
Thanks @kannibalox this is confirmed fixed. The impact of this change is about 15-20% in terms of performance which is great. I just have a quick question, since you seem to know how libtorrent works. When I startup my torrent client, it takes a few minutes to announce to thousands of UDP trackers. It also slows down my torrents because CPU usage is pegged at 100%. Would it be possible to announce/scrape UDP trackers on a new thread, then receive success or failure, once the task has been completed? It seems to me like this task can easily be separated by calling the success or failure event on completion. libtorrent/src/torrent/tracker_list.cc Lines 320 to 342 in 91f8cf4
I'd be happy to provide you with any necessary profiles and test your changes, should this task be feasible. |
I took a quick poke around the code and tried out a synthetic session with 10k UDP torrents, but didn't see anything immediately obvious. If you have profiles I wouldn't mind taking a look, but if it's truly CPU bound then threading probably won't be the answer. |
This should follow the same logic as before, which I double-checked by graphing the piece progress from the
LT_LOG_PIECE_EVENTS
log and confirming the same patterns showed up.In addition to the main change, this also makes some other performance improvements:
Block::insert
to return a NULL if the peer already exists, to avoid needing to scanning for the peer info twice.BlockList
uses a regularstd::vector
with the copy assignment/constructor disabled