It was reported (#2161) that enabling/disabling a downloading of a file
is considerably slow on libtorrent 1.0.3, but not on 0.16.x. The problem
is that a function torrent_file() in libttorrent 1.0.3 does a deep copy
of torrent_info, while get_torrent_info() in libtorrent 0.16.x only
returns a reference.
Sizes are now given in bytes.
Dates are Unix timestamps and converted to ISO 8601 in the web UI.
Numbers are not converted to strings.
-1 is returned for undefined values.
Some keys have been splitted:
Torrent list (json/torrents)
* num_seeds: Torrent seeds connected to
* num_complete: Torrent seeds in the swarm
* num_leechs: Torrent leechers connected to
* num_incomplete: Torrent leechers in the swarm
Torrent generic properties (propertiesGeneral/hash)
* total_uploaded: Total data uploaded
* total_uploaded_session: Total data uploaded this session
* total_downloaded: Total data dowloaded
* total_downloaded_session: Total data downloaded this session
* time_elapsed: Torrent elapsed time
* seeding_time: Torrent elapsed time while complete
* nb_connections: Torrent connection count
* nb_connections_limit: Torrent connection count limit
Global transfer info (json/transferInfo)
* dl_info_speed: Global downalod rate
* dl_info_data: Data downloaded this session
* up_info_speed: Global upload rate
* up_info_data: Data uploaded this session
Closes#1524.
Torrent numbers were recalculated on every dataChanged() signal. The previous commit
greatly increases the number of dataChanged() signals.
HEAD^^:
Total wall clock: 97.069s
updateTorrentNumbers() time: 0.033s
HEAD^:
Total wall clock: 96.132s
updateTorrentNumbers() time: 0.179s
HEAD:
Total wall clock: 95.535s
updateTorrentNumbers() time: 0.047s
After this commit the time of updateTorrentNumbers() is (almost) back to
the level that it was in HEAD^^.
In commit b50d733 TorrentModel moved from a periodic refresh, to using
postStatusUpdate(). In this transition I forgot to remove emition of
dataChanged() signal for the entire table.
According to my measurements this commit reduce CPU usage of qbittorrent
by a factor of 3:
Before:
Total wall clock: 97.07s
CPU time: 21.77s
- Time spent in TransferListDelegate::paint(): 14.60s
- Time spent in TorrentModel::forceModelRefresh(): 1.44s
- Time spent in TorrentModel::stateUpdated(): 0.02s
After:
Total wall clock: 96.13s
CPU time: 6.68s
- Time spent in TransferListDelegate::paint(): 2.63s
- Time spent in TorrentModel::forceModelRefresh(): <0.01s
- Time spent in TorrentModel::stateUpdated(): 1.73s
As it is seen the time spent in painting is reduced by a factor of 6 (14.60->2.63) at
the cost of slightly increased time of notifications that model is
changed (1.44->1.73). The next commits attempt to address this issue.
The problem is that torrentRow() does linear search over the list of all
available torrents. So it doesn't scale well for large number of
torrents. Removing the copying of QString from linear search
inner loop, speed up it considerably.
The proper solution should be using hash table instead of linear search.
This require more radical changes in TorrentModel and may be done in a
separate commit.
This commit probably fixes#2119.
The only important change in this commit is moving
session::get_ip_filter() from FilterParserThread::processFilterFile() to
FilterParserThread::run(). Previously we called it in main thread, but
now we calls it in worker thread. I don't now what libtorrent contract
about threads, but I assume that if it is ok to set_ip_filter from
other thread, it is ok to get it.
Qt uses binary search to convert string to QColor, we don't need that
binary search at all. This patch could be considered as optimization, but
in reality creating QColor takes only 0.2% of time. So it should be visible
at all.
This could be considered as cleanup for not calling expensive functions
from non-expensive ones.
libtorrent has a relatively heavy headers, that take lots of time to
process. This commit removes unnecessary includes of libtorrent headers
and replaces them with forward declarations.
I had to move some functions in QBtSession from slots to regular
functions because moc'ed file want to see complete types of all
parameters of slots.
"time make" of full rebuild before this series of commits:
real 13m35.937s
user 12m1.295s
sys 1m25.908s
after:
real 10m54.390s
user 9m31.167s
sys 1m12.580s
As we never use {push,pop}_front std::vector works here perfectly.
Also reserve memory for std::vector out of lock.
This could be considered as an optimization, but in reality this is just
using right container in right place. According to my measurements total
speedup is under 0.2%.
* also had to account for "Append the label of the torrent to the save path",
but again, this was only an issue when "Keep incomplete torrents in:" is
selected
* A multi-file torrent with only one file (ie: a single file within a folder),
was being treated as a single-file torrent, making it impossible to import.
Multi-file torrent detection code was copied from libtorrent. The
information is available in libtorrent (under torrent_info::m_multifile),
however it's a private member and I chose to go with copying the code that
determines it, rather than modifying a library qBittorrent depends on.
Conflicts:
src/torrentimportdlg.cpp
