starred/qBittorrent

Fork 0

mirror of https://github.com/qbittorrent/qBittorrent.git synced 2026-03-02 22:57:32 -05:00

Torrent checking is very slow #894

New issue

Closed

opened 2026-02-21 15:22:17 -05:00 by deekerman · 6 comments

deekerman commented

2026-02-21 15:22:17 -05:00

Owner

Originally created by @birdie-github on GitHub (Nov 6, 2013).

uTorrent checks torrents for half the time - I'm not sure it's a qBittorrent issue though - probably it pertains to libtorrent.

Originally created by @birdie-github on GitHub (Nov 6, 2013). uTorrent checks torrents for half the time - I'm not sure it's a qBittorrent issue though - probably it pertains to libtorrent.

deekerman closed this issue

2026-02-21 15:22:20 -05:00

deekerman commented

2026-02-21 15:22:21 -05:00

Author

Owner

@sledgehammer999 commented on GitHub (Nov 6, 2013):

Do you test the same torrent on the same disk/partition while no other process does heavy I/O on that disk/partition?

@sledgehammer999 commented on GitHub (Nov 6, 2013): Do you test the **same** torrent on the **same** disk/partition while no other process does heavy I/O on that disk/partition?

deekerman commented

2026-02-21 15:22:22 -05:00

Author

Owner

@birdie-github commented on GitHub (Nov 7, 2013):

Yes, absolutely - none of this applications is IO bound - they are CPU bound.

uTorrent btw is running under Wine.

@birdie-github commented on GitHub (Nov 7, 2013): Yes, absolutely - none of this applications is IO bound - they are CPU bound. uTorrent btw is running under Wine.

deekerman commented

2026-02-21 15:22:22 -05:00

Author

Owner

@Kervius commented on GitHub (Nov 7, 2013):

I wouldn't use word slow, but my impression is that qbt's checking is somehow (over)loads Windows very much: everything accessing disk gets very unusually slow during checking. Judging by the slowness, I think that heavy disk seeking taking place. IOW I/O is not as expected sequential, but rather random, leading to the crippled performance.

(Does qbt per chance updates the state of the torrent while checking? and does qbt uses sync writes during such updates? Something like this would explain the slowness.)

@Kervius commented on GitHub (Nov 7, 2013): I wouldn't use word slow, but my impression is that qbt's checking is somehow (over)loads Windows very much: everything accessing disk gets very unusually slow during checking. Judging by the slowness, I think that heavy disk seeking taking place. IOW I/O is not as expected sequential, but rather random, leading to the crippled performance. (Does qbt per chance updates the state of the torrent while checking? and does qbt uses sync writes during such updates? Something like this would explain the slowness.)

deekerman commented

2026-02-21 15:22:22 -05:00

Author

Owner

@birdie-github commented on GitHub (Nov 8, 2013):

Hey, I'd use the word "twice as slow" - and I can upload a youtube clip showing the speed of a torrent checking for a torrent residing on tmpfs (so disk IO has no effect).

@birdie-github commented on GitHub (Nov 8, 2013): Hey, I'd use the word "twice as slow" - and I can upload a youtube clip showing the speed of a torrent checking for a torrent residing on tmpfs (so disk IO has no effect).

deekerman commented

2026-02-21 15:22:22 -05:00

Author

Owner

@sledgehammer999 commented on GitHub (Nov 21, 2013):

Uhm, why did you close this? Was it fixed somehow?

@sledgehammer999 commented on GitHub (Nov 21, 2013): Uhm, why did you close this? Was it fixed somehow?

deekerman commented

2026-02-21 15:22:22 -05:00

Author

Owner

@birdie-github commented on GitHub (Nov 21, 2013):

This must be fixed in libtorrent but I'm too lazy to file a bug report.

Probably their method of checksumming is not very optimized.

Anyways, this bug has nothing to do with QBT ;-)

@birdie-github commented on GitHub (Nov 21, 2013): This must be fixed in libtorrent but I'm too lazy to file a bug report. Probably their method of checksumming is not very optimized. Anyways, this bug has nothing to do with QBT ;-)

deekerman referenced this issue

2026-02-21 15:46:15 -05:00

Failed to load the torrent: metadata too large #1637