Only few file managers are able to select files when started from the
command line.
xdg-mime is required to retrieve the default file manager. If it's not
available or the file manager is not able to automatically select files,
the containing directory will be opened as usual.
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.
This commit should improve performance when user navigating through
torrent list using up/down keys. A scrolling through all the list
(276 torrents) took:
Total wall time: 18.813s
Total CPU time: 3.210s
misc::parseHtmlLinks(): 0.096s
misc::parseHtmlLinks() is 8th most hottest function on
this use case.
This commit caches icons in TorrentContentModel in the same way they are
cached in TorrentModel.
This commit should improve performance when user navigating through
torrent list using up/down keys. A scrolling through all the list
(276 torrents) took:
Total wall time: 18.813s
Total CPU time: 3.210s
IconProvider::generateDifferentSizes(): 0.170s
IconProvider::generateDifferentSizes is 5th most hottest function on
this use case.
I thought merging all 3 sort-filter proxy models into one should
speedup dataChanged() signal. As turned out this is not the case. The
time difference is within inaccuracy range, so this doesn't affect
performance.
But I still think it is good to merge them into one proxy model as it
simplifies code.
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.
sledgehammer999