Torrent Sorting #6219

Open
rsgabriel opened this Issue Jan 9, 2017 · 11 comments

Projects

None yet

4 participants

@rsgabriel

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.

@evsh
Contributor
evsh commented Jan 9, 2017

What is your environment, please (qBt uses its own implementation of natural sorting on Windows and with Qt 4)?

@rsgabriel

Running qB 3.3.6 on Windows Server 2012 64-bit, Intel Core i5 4460 @3.2Ghz w/ 32GB RAM.

@evsh
Contributor
evsh commented Jan 9, 2017

Thanks. You are using the custom code.

@Chocobo1, did you perform any profiling or speed tests for NaturalCompare?

@Chocobo1
Member

I think you mean lessThan(), no I didn't.

@evsh
Contributor
evsh commented Jan 10, 2017

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.

@rsgabriel

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.

@evsh
Contributor
evsh commented Jan 11, 2017

Can memory fragmentation lead thus far? @rsgabriel, can you please, monitor qbt memory usage should you see such behaviour one more time?

@sledgehammer999
Contributor

Don't forget that v3.3.10 is latest and it has 64bit official release too.

@rsgabriel
rsgabriel commented Jan 11, 2017 edited

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.

@sledgehammer999
Contributor

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.

@rsgabriel

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment