cpu usage in new version(2.0) unreasonably high even when iconified.

[GoogleCodeExporter]

I have a total of 644 torrent listed under transgui, which isn't that many.

(Many = few to several thousand).

The new version is OFTEN not-responsive -- the GUI is ignored/locked out while 
it is updating -- which it is taking WAY too long to do.  Right now I have it 
set to only update once every 10 seconds, because otherwise, it stays locked up 
too long to be useful.  If games doing 3D drawing and complex physics 
calculations can update the screen 60 times/second, why 
is this data display taking 100's of times the cpu power to display text?

For comparison -- with the same information, utorrent can run once every 2-3 
seconds and still be responsive and use nowhere near the same CPU. 

Attached is a resource graph as plotted from process explorer.  The cpu
graph is scaled to 1 cpu.  Notice it is at over 50% about half the time.
Considering all it is doing is gathering data and displaying it, it shouldn't 
be using hardly any cpu time at all.  

It was *borderline* (I had to slow down the updates from 1-2 seconds to once/5 
seconds) -- 3-7 seconds is about right for real time info like this, but now 
it's at 10 and the gui is often non-responsive.

Now Couple things -- 1) you could use multiple threads, but that would
spread out the cpu usage among multiple cpu's if people have them.  It doesn't 
solve the underlying problem of why they code is eating so much 
cputime.  
2) multiple threads would still be good -- have one to operate the gui, one to 
gather info from transmission, and maybe a 3rd to do everything else (maybe 3rd 
isn't needed if there is nothing else), but it should lock out user input while 
it is gathering info from transmission.

So...at least you have to put the read from transmission NOT in the same loop 
as your even processor for your gui.  That would help the responsiveness issue. 
 But that's glossing it over with more cpu's -- should try to figure out what's 
taking so long.  

Ever thought of moving it to C or C++?  ;-)

Original issue reported on code.google.com by astara.a...@gmail.com on 24 Aug 2010 at 2:00

Attachments:

• transgui-cpu-w640.png

[GoogleCodeExporter]

Such CPU usage is too high. I usually have about only 30 torrents and did not 
optimize the code for thousands torrents. 
What the CPU usage on 1.4 version with the same number of torrents?
I will try to emulate your scenario and fix the bottleneck.

P.S. Free Pascal compiler makes as fast code as C/C++ compilers. The problem is 
in coding :)

Original comment by j...@cp-lab.com on 24 Aug 2010 at 7:44

• Changed state: Accepted

[GoogleCodeExporter]

Try this version:
http://transmisson-remote-gui.googlecode.com/files/transgui-2.1.1-setup.exe

Original comment by j...@cp-lab.com on 25 Aug 2010 at 1:22

• Changed state: Feedback

[GoogleCodeExporter]

Much better.  Still seems high for what it is doing, but compared to before, .. 
night and day...there are still spikes like in the previous graph, but between 
them, it's pretty quiet now, which is good.  

I know there's going to be periodic spikes, well, I'll attach another graph in 
a while, after it's filled up a page, but substantially better, thank-you!...

As for my comment about Pascal.  I would suspect it can produce at least as 
good as good as C++, though C++ code is not always as efficient as C code in 
the minutiae, its just that Pascal is so much more verbose! that C.  

I was *forced* to learn it as my *first* programming language in college and 
remember struggling with it and the thing that I had the most problems with was 
all the long keywords BEGIN/END vs. {} ...  even assignment, the most common 
thing possible, was twice as long as need be (':=' (or is it '=:') vs. '='). 
etc...  Plus C had little shortcuts like the ++a instead of a=a+1, or a*=3; for 
a=a*3, and many times is the a++ useful in place of the ++a, where you want to 
test a limit before it incremented or decremented, but want the post value 
processed aftewards;  I can't see that *anyone* would find it faster to program 
in Pascal than in C, since they are very similar.  

That's my biggest issue with Pascal that I remember.  We had 1 lesson where we 
had to use 'Cobol' in a course of sampling computer languages, ... much much 
worse -- if you don't know, consider yourself fortunate.  

Perform multiplication of X times 3 putting the result in X, instead of "x*=3".
(^error...forgot period at --------------------------------^)
(it would have error messages like that -- it knew what you meant, why didn't 
it just put them in!?!  Grgrh)

AAIIEEEE!!!....  If they wanted to make me very afraid, they did.

...
oops...wrote so long, it finished the graph...attching new file...you can see 
there are gaps between the cpu usage -- still some interesting 'harmonic' wave 
patterns,  Each vertical line looks to be 10 seconds apart - or the time 
between screen updates.

It's weird how it makes a 2 wave-patterns -- a faint one that goes between 55% 
and 100% of a CPU every 10 cycles.  Then there's a lower, thicker wave pattern 
that also goes up and down in 100 second cycles that goes between about 50-75% 
of a CPU, in sync with the lighter one.  I wonder if that correlates to some 
behavior in your program or if there's something else it's interacting with on 
my machine....

*it's all black magic* (black!=bad...just dark, not too many lights inside most 
computers).

Original comment by astara.a...@gmail.com on 26 Aug 2010 at 12:04

Attachments:

• transgui-cpu-scaled-w1024.png

[GoogleCodeExporter]

Transmission Remote GUI have 2 threads. The main tread and the background 
thread, which fetches data from the daemon. Probably that causes such graph.
Transmission uses CPU unfriendly JSON text format for RPC communication and it 
causes extra CPU load on high data volumes.
It is possible to tweak the code a bit more, but the result does not worth the 
needed efforts.

Original comment by j...@cp-lab.com on 26 Aug 2010 at 7:37

• Changed state: Fixed