Closed GoogleCodeExporter closed 9 years ago
It had already been made into a hierarchical view when you opened the ticket,
but the selection features you mention were lacking.
I'd been putting it off because of the increasing overlap of the torrent add
dialog and the files tree view. Duplicate code needed merging and the behavior
needed to be more consistent, so I've just done that.
It's committed, almost complete. There's an issue with preferences not being
propogated upwards correctly which I'll fix.
Original comment by a...@eth0.org.uk
on 4 Jan 2012 at 11:57
Should be fixed now.
Original comment by a...@eth0.org.uk
on 4 Jan 2012 at 4:56
Ah, guess I should have tried trunk before creating a ticket for the feature. I
just tried it, and the hierarchical file tree works very well, including the
way it collapses all subfolders when you collapse a parent.
However, torrents with large number of files now cause a huge spike in CPU
usage when you select them, with a sometimes very noticeable pause before the
GUI becomes responsive again. The worst case in my testing was a torrent with
5000+ subfolders in a relatively flat hierarchy, which caused
transmission-remote-gtk to hang for 20 minutes on my Macbook (2.0GHz Core 2
Duo).
Original comment by gardne...@gmail.com
on 4 Jan 2012 at 10:37
Ouch, that's not good. I'll have a think and see what I can do sometime.
Is there a noticible freeze if you open that torrent using the torrent add
dialog? I can understand why the main files tree view is slow doing large flat
directories - the inserts are done in a bit of a lazy way, just searching over
each level for each file until it finds its parent. This is partly because I
wasn't sure if there's any guarantees about order. There's definitely
optimisation I can do, though.
The .torrent files get parsed into a convenient tree before inserting into the
GtkTreeModel. Building the tree uses a similar algorithm, but I'd be interested
to see how doing that on simple data structures instead of the GtkTreeModel
compares.
I don't have any torrents like yours to test with. Would it be possible to send
me that 5000 one via email?
Original comment by a...@eth0.org.uk
on 5 Jan 2012 at 8:33
There's still a noticeable freeze with the torrent add dialog, but it's only a
couple minutes for the 5000+ torrent.
If a more efficient algorithm would be possible given some particular ordering,
what about just sorting the data before building the tree? That amount of data
should be nothing to an O(n log n) algorithm like mergesort.
I've also emailed you a link to that torrent, for testing.
Original comment by gardne...@gmail.com
on 5 Jan 2012 at 9:45
Thanks, I'll try to apply a similar solution (whatever that is) to both the
torrent add and regular file model. It's the same crappy algorithm in the add
dialog, just less code/complexity which gets run by it.
I did think about sorting before inserting, the problem is that the ordinal
position of the file in the elements array is important. It's saved as a column
in the model, because it's required when sending enabled/priority changes to
Transmission.
Transmission seems to just send the order it parsed out of the torrent file -
which is always in order as far as I've seen, but I think that's because of the
creating app and therefore not guaranteed.
My idea right now is to maintain a stack of references to parents and their
names, for the last insertion. I'm fairly sure this will work well, just
thinking about it. It should be able to recall the parent without searching
(just a few strcmp) if it hasn't changed, and if it has will only need to
search the levels necessary.
Unfortunately magnet links complicate this a little, as magnet torrents can
suddenly appear with new files, but it shouldn't be too much of a problem.
Original comment by a...@eth0.org.uk
on 5 Jan 2012 at 3:52
The changes I pushed recently completely fix this for the torrent add dialog,
which builds up its own tree first. Checking the previous addition instead of
searching seems very fast with that torrent you gave me.
Unfortunately the main files one still needs work. I did try to do something
like the above for this too - using the GTK model but it turned out horribly
slow. Maybe building up a tree first is the fastest way.
A relatively simple change to the update parent sizes code has made it much
faster, though.
Original comment by a...@eth0.org.uk
on 8 Jan 2012 at 11:27
Hi,
Give it a try and let me know. Both tree views work quickly for me now.
Original comment by a...@eth0.org.uk
on 9 Jan 2012 at 9:55
There's now only a 1-second delay when selecting that large torrent in the main
torrent list, which is a vast improvement over the multi-minute delays I was
getting before. (I should mention that I'm on a much faster connection to the
transmission-daemon than I was on before; with this connection the previous SVN
head was giving me 3-minute hangs instead of the 20-minute hangs I was getting
on a slow internet connection. I no longer have that slow connection to test
on, unfortunately.)
Thanks for the improvements! Any idea when you'll be cutting a new release?
Original comment by gardne...@gmail.com
on 10 Jan 2012 at 11:17
Thanks for the feedback.
Unfortunately a torrent with that many directories in any given level
potentially has a lot of iterations to do for every entry under it. It's
because it needs to check them to figure out the priority of the parent (ie.
mixed or fully changed). Using simple data structures before putting it in GTK
has made this much faster, though.
Anyhow, I've just done one more optimisation and I'm happy with the performance
now. Taking advantage of the tree not being glib/gtk anymore, it now uses a
thread to build that tree only if there's more than 600 files.
Not sure if it's faster, but it feels faster without the UI freeze.
Original comment by a...@eth0.org.uk
on 11 Jan 2012 at 8:04
Original issue reported on code.google.com by
gardne...@gmail.com
on 2 Jan 2012 at 11:21