I've the following conditions:

1. OpenSUSE 11.2
2. KTorrent trunk version
3. Torrents are located on external USB Drive (Transcend, don't think the model doesn't play any role). The filesystem is vfat (as all flash drives are).
4. 37Gb size torrent
5. 167 files in torrent

Bug simptoms:

Each 10 seconds when ktorrent tries to check disk usage:

1. It takes 15 seconds for

Code: Select all

cman->diskUsage()

on this torrent in

Code: Select all

bool TorrentControl::checkDiskSpace(bool emit_sig)

. And UI is freezing for that time.

2. The picture in top(1) is more awful. It takes up to 50% in wait time.

Cpu(s): 5.6%us, 4.0%sy, 0.0%ni, 44.4%id, 45.2%wa, 0.8%hi, 0.0%si, 0.0%st

Of cource it slows down the system.

Suggestion

I've profiled the process and found out that the problem is caused by opening/closing files in CacheFile::diskUsage(), i.e there only several files from the torrent are opened in every moment. And other files (there are 167 of them) must be opened and closed according to current implementation.

So the suggestion is don't open file if only

Code: Select all

diskUsage()

is required. Non-windows version of the patch looks like this:

Code: Select all

+++ libbtcore/diskio/cachefile.cpp

        Uint64 CacheFile::diskUsage()
        {
                Uint64 ret = 0;
                bool close_again = false;
                if (!fptr)
                {
+#ifndef Q_WS_WIN
+       #ifdef HAVE_FSTAT64 // Hope that is I have stat64 when fstat64 exists :)
+                       struct stat64 sb;
+                       if (stat64(QFile::encodeName(path),&sb) == 0)
+       #else
+                       struct stat sb;
+                       if (stat(QFile::encodeName(path),&sb) == 0)
+       #endif
+                       {
+                               return (Uint64)sb.st_blocks * 512;
+                       }
+#endif
                        openFile(READ);
                        close_again = true;
                }

This patch has fixed my problem and I think it is better for faster hard drives where the problem isn't visible.

I could commit myself but I'm not sure about SVN permissions.

Strange, I wasn't aware opening and closing of files could take up that much time.

It's probably best I find a windows equivalent for stat, so we don't have to open the file on windows.

OK, found a windows equivalent, and have committed the fix.