When sorting a large numbers of torrents (5k+), the sort takes a long time. There's no indication of progress or status on the sort, and I can click other headers and its not clear what is going to happen if I do that since the ASC/DSC arrow does not appear in the new row.
If I'm filtering by viewing a particular category, tracker, or status, the sort takes just as long as sorting the entire list.
Ideally, each category/tracker could have its own sort preference. In one category I might be interested in ratio, in another added date, another save path and switching between category/tracker/torrent status would update the view accordingly, remembering the way that particular list is sorted.
At the least, it would be nice if the current view could be sorted first, and then the entire list sorted after, and maybe columns unclickable until the sort is complete, or some indication that the sorting parameter has changed when the column is clicked.
What is your environment, please (qBt uses its own implementation of natural sorting on Windows and with Qt 4)?
Running qB 3.3.6 on Windows Server 2012 64-bit, Intel Core i5 4460 @3.2Ghz w/ 32GB RAM.
Thanks. You are using the custom code.
@Chocobo1, did you perform any profiling or speed tests for NaturalCompare?
I think you mean lessThan(), no I didn't.
I duplicated names of my torrents to fill 5k+ list and called std::sort() with lessThen():
List size is 6185
Sorting took 3.794000e-03 seconds
Then, I think, the problem is not in the custom natural sorting implementation.
So I had yet another "add a bunch of torrents and the client crashes" event and now sorting is super fast (<1second) again.
Maybe some kind of lag is introduced as the client stays open for extended periods of time?
I restarted the client yesterday and currently using ~791MB of program memory. Total waste is at 296MB.
Can memory fragmentation lead thus far? @rsgabriel, can you please, monitor qbt memory usage should you see such behaviour one more time?
Don't forget that v3.3.10 is latest and it has 64bit official release too.
I can try the 64 bit version after I reproduce this again. I have no problem throwing more memory at this for now but its not an ideal solution to this issue.
EDIT: Of interest, sorting today takes about 1 second, just slightly longer than previously.
Process memory is @820MB, waste is 220ish but I am noticing that average time in queue is a little higher today, i saw a max of maybe 1800ms yesterday but today I'm seeing numbers as high as 3200ms.
My 2 cents: There was one or two reports of users saying that after days of active work network speeds started slowing down or that the GUI was sluggish. And that always a qbt restart solved the problem.
I have no idea what is happening nor what to look for.
A restart wouldn't be an issue were it not for the sometimes many torrents that go to "missing files" or go from 100% complete to some partial amount requiring redownload.