Version: svn rev. 1055584 (using KDE 4.3.3) Compiler: gcc (Gentoo 4.4.2 p1.0) 4.4.2 OS: Linux Installed from: Gentoo Packages Since version 3.3, KTorrent causes a very high cpu load almost immediately after starting. KTorrent keeps using more than 60% of one core with peaks up to 100% (also while not actually uploading anything), probably because I am seeding about 850 Torrents. Scrolling or clicking in the list of torrents is slow and can take up to 10 seconds. With KTorrent 3.2.3, I had about 15% cpu load for the first seconds, and afterwards about 2% in idle mode as well as with many connections and maximum upload speed. (Also, I think the memory usage was a little less.) Both times, the only loaded plugin was UPnP.
Is DHT enabled ?
Yes, but turning it off does not really help. Maybe it is a little bit better, but still far too slow and far too much cpu load. Shall I attach output from the Log Viewer?
It would be interesting if you could run ktorrent with profiling on. Do you know how to use oprofile ?
Sorry for taking so long. I have tried to use oprofile, but it refuses to measure anything. All I get is a hint that all samples get lost due to cpu buffer overflows and that I should lower "the sampling frequency". However, I could not find out what sampling frequency is ment, what it will affect and where I can change it. With the latest KTorrent version (3.3.3) I do not get as bad results as before. The cpu load stays between 5% and 20%, but which is still pretty much. It only raises up to >80% when scrolling in the torrent list.
SVN commit 1143060 by guisson: Improve performance of ViewModel when there are many torrents BUG: 216501 M +1 -0 ChangeLog M +4 -5 ktorrent/view/viewmodel.cpp M +1 -1 ktorrent/view/viewmodel.h WebSVN link: http://websvn.kde.org/?view=rev&revision=1143060
Sorry, this did not help much. I have currently 1094 torrents in the list (1092 seeding, 2 stalled). With the current snapshot, the cpu load stays near 100% on one of two cores. Some actions (like right clicking on the ktorrent symbol in the icon tray) turn the whole desktop unresponsive. However, I finally managed to get some results with oprofile. I will attach them (two files). Tell me if you need more information.
Created attachment 49812 [details] opreport --demangle=smart --symbols /usr/bin/ktorrent
Created attachment 49813 [details] opreport --demangle=smart --symbols /usr/bin/ktorrent -cl bzip2 compressed as it was too big
Can you give me a report without the cycles ? (without -c)
Sorry, I do not understand what command exactly you want me to run. As far as I understand, -c shows the callgraph. The report without callgraph is in the first attachment.
Yes, I overlooked that. Looking at the results, the function using the CPU the most is somewhere deep inside harfbuzz (which is a text layouting library used by Qt). Can you increase the GUI update interval in the advanced settings to 5000 ms ? And see what that does for CPU usage.
This helps much. CPU usage drops down to about 30% and the GUI is much more responsive. So does this need to be improved in Qt?
I have a feeling it is caused by the GUI update of the torrent list. Because you have so many torrents, to much dataChanged signals get emitted. Emitting many signals can be very slow.
Can you try rev 1162787 of trunk ? In this revision only one dataChanged will be emitted every GUI update, in theory this should be faster. Make sure you try it with a GUI update interval of 1000 ms.
Sorry for not answering for so long. As I had ongoing problems with the proper function of KTorrent, I could not look at the performance. Now with KTorrent 4.0.5, it runs much faster than with some older versions. Still, the cpu usage is higher than with KTorrent 3.2.3, but it is running smooth now.