#1
|
|||
|
|||
![]()
go to Settings / User Interface, change the Style to Windows Style , than under Performance take the check out of windowdecoration.. restart JD if asked.
next click Advanced under User Interface and disable the SpeedMeter graph .. go to General and set the logging level to OFF .. *note don't ask for support without a log.. restart JDownloader ... ah , much better :] i haven't tested it but disabling unused addons might help with memory / speed as well .. any other tips ? edit: updated for latest version. Last edited by sunnytimes; 20.09.2009 at 21:17. |
#2
|
|||
|
|||
![]()
The best performance enhancer that I've found is to minimise the jD window. It consumes much less CPU cycles.
It seems that the Downloads panel is the cause. |
#3
|
|||
|
|||
![]()
You're right, Remi.
Minimizing the app does make a difference. And this only goes to show what a bad idea it was to redesign the GUI. Not only does it not bring anything truly useful but as it turns out it's a huge resource hog. At times mem consumption shoots up to 6-700 megs. ![]() Some of the nastier bugs have been ironed out though. No more RS CRC errors, proper link parsing at last. Let's cut the devs some slack and wait it out. |
#4
|
||||
|
||||
![]()
if the jd process has more than 512mb ram then its a memory leak between java and windows. jd cannot use more than 512mb because thats max heap!
also the cpu usage with downloadview is known and we are working on that, but its hard because the increase comes from the used look and feel...but im sure we will be able to make it better. so stay tuned...
__________________
JD-Dev & Server-Admin |
#5
|
|||
|
|||
![]()
I still don' know why the application has been redesigned. It's not only a matter of the Human-Machine Interface. I've discovered certain changes in the way the configuration files are stored as well. The fact that the host plugins couldn't be updated anymore, proves that some parts of the kernel were redesigned as well.
![]() Edit by jiaz: no changes in config system was made! also host plugins can still get updated as before, no changes here! but new plugins cannot be used for older version because of too much changes inside jd What I've discovered in the change logs, is that Jiaz has been closely involved in, if not responsibe for, the development of v.0.5. You can also feel this in the way he reacted to the many negative posts on this forum. He had to solve many bugs introduced by this redevelopment. Edit by Jiaz: ive done the redesign of the linkgrabber and rewrote many internal parts (downloadcontroller, linkgrabbercontroller, lincheck and many more) and of course this is not easy and bugs can happen...im glad about every proper reported bug and will fix it and have done this all the time...but i dont understand ppl complaining about it and dont help us to improve or fix, because a *sxxx jd* does not help at all ![]() As I'm running both v.0.4 and v.0.5 I can tell that technically the HMI of v.0.5 doesn't consume more CPU cycles than that of v.0.4. I've reported that earlier and nobody has contradicted this observation. In v.0.4 it might not have been possible to increase the HMI performance. Just a guess. Edit by jiaz: substance (look and feel) has a performance issue in all treetables (downloadlist and linkgrabber), but im sure we will be able to find a way to improve this Of course, and I repeat this for the zillionth time, the usability of v.0.4. is higher than that of v.0.5. As soon as I have the time for installing and testing v.0.6 or a higher version I'll publish a new comparison report on usability. Edit by jiaz: usability is very important and we listen to our users and change to their will (we did that alot during beta and release candidates) and will do this in future too (eg move buttons)...but gui fixes/changes takes alot of time! Last edited by Jiaz; 17.06.2009 at 14:04. |
#6
|
|||
|
|||
![]()
i like your style remi...
|
#7
|
|||
|
|||
![]()
Jiaz,
I just saw your edits. Many thanks for your time. I understand a little more now. ![]() deinemudder, It's probably due to my scientific background... ![]() |
#8
|
|||
|
|||
![]()
Just trying to be helpful.
Last edited by kent565; 10.09.2009 at 23:52. Reason: None |
#9
|
||||
|
||||
![]()
its mostly the gui that has the high cpu usage
without gui, 2mb/s download with 20 downloads uses less than 1% cpu over here....the gui takes the most amount...but normally the user minimizes the app to the tray ![]() ![]() we will not rewrite it in another language because this would take alot of times and the multios would be MUCH MUCH harder to achieve. we are still working on performance issues and under normal circumstances jd should have max 15-20% while gui is open. with gui closed 0-5% should be normal. Edit: i deleted your other post, pls no double post
__________________
JD-Dev & Server-Admin Last edited by Jiaz; 05.09.2009 at 22:25. |
#10
|
|||
|
|||
![]() Quote:
Quote:
I'm running Azureus on an old PC as well and I've no performance problems with it. I'm running more than 10 torrents simultaneously. Quote:
I do think that native, compiled code is faster than interpreted code, but today's CPUs are so fast that the difference is barely visible for the applications you're talking about. Thanks for your contribution that contains a lot of truths, but also grossly exaggerates some of the advantages of C++. Last edited by remi; 06.09.2009 at 11:36. |
Thread Tools | |
Display Modes | |
|
|