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.

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.

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.

[Jiaz]

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...

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!

i like your style remi...

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...

Just trying to be helpful.

[Jiaz]

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 *dont think there is much sense in seeing the download progress all the time *

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

Originally Posted by kent565

the high CPU usage (which is not the developers fault)
it's the use of java.

Like Jiaz said, it's the problem of the GUI. The jD team has tried several solutions and the best GUI thus far was that of jD v.0.4. If you minimise the jD v.0.4 window, the application consumes almost no CPU cycles.

Originally Posted by kent565

If anyone has ever used the following torrent applications: 1.)µTorrent 2.)Azureus
they will notice something immediately Azureus look good but is useless this program cannot
download more than 3 torrents a without consuming 100% of CPU, on the other hand with µTorrent
can downlod over 500 torrents and the CPU footprint remains exactly the same about 2% CPU.
So there's the example and the problem.

I've used µTorrent and it crashed my PCs on a regular basis, losing all the torrents' statae and torrent list. I've lost so much time with that application that I've decided to stick with Azureus.
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.

Originally Posted by kent565

Azureus is written using java [java is not good for any application it's unstable,useless
and should be obsolete]. µTorrent is written in C++ and no JAVA it is written perfectly
it has all the bell and whistle of Azureus but unlike Azureus µTorrent looks good,feels great
and works flawlessly. Azureus is a car without wheels, looks good
but cannot do the job i was designed to do.

Java isn't useless. An endless number of applications has been written in Java. As all programming languages, including C, C++, etc. Java has had its time, but I don't know any better alternative. C++ is less secure than Java and Java is easier to program in. That's why Java is so popular among developers. C++ programming is extremely complex and it's not a surprise to me that C++ programs on average contain more bugs than Java programs.

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++.