Printable View
Ok I am coming from a C based world here but when I started learning about Java I was shocked to see how much RAM and CPU cycles it used even when doing very simple tasks.
It takes 17 MB of ram and around 36 CPU cycles just to write "Hello" in an applet!
When I was working with C that would only take 2 MB of ram and around 16 CPU cycles.
Is there any way to make Java faster? Otherwise I am going to be stuck when I make more complex programs. :-/
It's possible that Java isn't fast enougth for your application but Java isn't that much slower than C really.Quote:
Originally Posted by David2010
It's true that Java allocates many resources up front. Also Java is a slow starter when it comes to speed. But in large application when the runtime optimizations kick in the difference to C shouldn't be that big.
Also in complex programs the throughput rarely is dependent on the raw speed of individual language constructs. Instead it's the choise of algorithms & data structures and the overall design that ensures a fast program.
Yeah my first big mistake was that I didn't know that java doesn't assign RAM linearly.Quote:
Originally Posted by nuzzle
I found several neat techniques that helped such as:
Changing my ints to bytes for the smaller numbers and when I had a LOT of integers I would use one big array instead.
Use booleans for true and false instead of integers.
and many other simple optimizations.
Please don't treat Java as C. It is not low-level procedural language, it is exact opposite of that. You can't see connection to CPU or RAM from Java as you would with C.
I agree with what has been said - don't treat Java like C. If you do you can as well keep using C.Quote:
Originally Posted by David2010
Java is a totally different ballgame really. Concentrate on writing beautiful code rather than "sweating the small stuff".
I agree with Nuzzle & Postmortem.
The rule-of-thumb guidelines for optimising in Java (and most high-level languages) are:
1. Don't do it.
2. Don't do it yet.
3. Measure the performance problem first.
4. Use a profiler to find the bottleneck(s) to address.
Obviously, there are situations where experience tells you in advance that you will need to use some particular approach or technique, or the language itself suggests it (e.g. String vs StringBuilder concatenation in loops), but the general principle is only optimise a measurable problem after using a profiler.
We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil...
D. Knuth
I think this "premature optimization is evil" rule by Knuth is very misunderstood. It does NOT translate to this,Quote:
Originally Posted by dlorde
1. Don't do it.
2. Don't do it yet.
3. Measure the performance problem first.
4. Use a profiler to find the bottleneck(s) to address.
This is NOT what Knuth had in mind.
I think what Knuth had in mind was that you should program at the highest abstraction level the language offers. Optimization is when you go down in abstraction and become more specific. Don't do that prematurely is what Knuth meant.
What you on the other hand should do is laying down efficient code all the time (at the appropriate abstraction level). That isn't premature optimization in the Knuth sense. That's your obligation as a professional programmer.
Knuth's rule is often interpreted as it doesn't matter at all what code programmers lay down because afterwards performance bootlenecks can always be found and fixed. This is very wrong. Programmer's ability to always lay down the most efficient code is extremely important for a nimble program in my view.
I didn't actually intend the Best Practice optimization guidelines I posted to be an expansion of Knuth's quote; rather the quote, as usual, was simply a topical addendum. The guidelines are just a popular extension of M.A. Jackson's original tongue-in-cheek 'Rules of Optimization' :
Rule 1: Don't do it.
Rule 2 (for experts only): Don't do it yet.
Clearly one should try to write efficient, clear, maintainable code, and Knuth is certainly in favour of well-written code at an appropriate level of abstraction.
One can get a better idea of what Knuth meant by that quote about optimization by seeing it in context:
"There is no doubt that the grail of efficiency leads to abuse. Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3 %. A good programmer will not be lulled into complacency by such reasoning, he will be wise to look carefully at the critical code; but only after that code has been identified. It is often a mistake to make a priori judgments about what parts of a program are really critical, since the universal experience of programmers who have been using measurement tools has been that their intuitive guesses fail."
He also mentions, when explaining some example code:
"... again we see the advantage of delaying optimizations until we have obtained more knowledge of a program's behavior."
and when talking about techniques for code validation:
"A similar thing should be considered standard practice for all but the simplest software programs: A programmer should create a program P which is readily understood and well-documented, and then he should optimize it into a program Q which is very efficient."
It seems to me that what he says isn't so far from the Best Practice guidelines.
There is a famous rule in performance optimization called the 90/10 rule: 90% of a program's execution time is spent in only 10% of its code. The standard inference from this rule is that programmers should find that 10% of the code and optimize it, because that's the only code where improvements make a difference in the overall system performance. But a second inference is just as important: programmers can deoptimize the other 90% of the code (in order to make it easier to use, maintain, etc.), because deterioration (of performance) of that code won't make much of a difference in the overall system performance...
R. Pattis
Well, actually it is. Check out his home page if you don't believe me. Or you could take dlorde's word for it (given the quotes from Knuth himself).Quote:
Originally Posted by nuzzle
I don't completely disagree with your opinion though. I sit somewhere in between your opinion and that of Knuth in that I think that you SHOULD consider performance of your system before writing the code. If you do not know what part of your code is the critical section, then you shouldn't be writing it :D. You won't find all of the bottlenecks until it has been released (or in QA for a sufficient amount of time), but you should be able to initially optimize certain parts that you "should" know are critical sections beforehand.
Yes, I'd go along with that. But it does take a little experience, and until a little experience has been gained, the guidelines are useful. Obviously, it depends on the context of the code, but from my reading, opinion has moved towards readability and maintainability taking priority until an efficiency or performance problem can be demonstrated - and readable, clear code is generally more elegant code, and elegant code is generally more efficient than sloppy code... [broad generalisations, of course].Quote:
Originally Posted by ProgramThis
Fancy optimizers have fancy bugs...
R. Pike