Actually, it's pretty lousy. You have a 2% death rate per flight. That's worse than base jumping (jumping off mountains/cliffs/fixed structures with parachutes, base jumping is often illegal.) About the only thing I know with an equivalent death rate is climbing everest.
Actually, I think he's wrong about the universe dying in a cold universe. The expansion of the universe is accelerating, so as this continues the visible edge of the universe will come closer and closer over time (it's currently about 13 billion light years away, but it's approaching us). Eventually the visible edge will be closer than molecules- at that point all the molecules in the universe fall apart since the electromagnetism will no longer hold them together. Soon after, it will be smaller than nuclei- and then the weak force fails, and bye bye universe.
It's quite dated (Unix 10 years ago, did suck fairly badly in some ways, although not as badly as Windows 95!), and getting exponentially more so. The book was actually fairly humorous, it loses a lot in its translation to the web. The book is well out of print in both senses of the word 'well'.
I was (un)lucky enough to work next to a moslem guy who admitted on sept 11 that 'actually I'm on their side'. Interestingly the guy scored 105 on an IQ test (I score 155, and the test way, way overestimated my IQ).
Still, the vast, vast majority of Moslems condemned Sept 11.
Yeah, that's pretty much so. My understanding is that a bent fiber, no matter how slight the bend, eventually snaps. You can delay the inevitable by making the bend less acute though. By the time you get to a bend radius measured in 10s of cm the lifetime is probably in the multiple decades.
bully Sun to add -Xnotrace option to disable stack trace in exceptions and make them efficient?
Nasty! So it throws an exception and you don't know where it came from; ever? YUCK.
Its nonsense to change class design because some feature that could be fast happens to be slow.
No, or yes, depending on what you mean here. The right thing to do is to create a new exception type that doesn't fill in the exceptions- for this kind of use.
It's never necessary to use exceptions; but it's nearly always a good idea.
I figure when I'm being paid to do some work; it's more or less my job to do it the quick/short/lazy way rather than the long way (provided it doesn't do horrible things to the code maintenance or otherwise make the code unnecessarily brittle to changes.)
Doing otherwise does nasty things to the profitability of the company- and I and the rest of the people I'm working with can end up out of a job.
Actually I'm pretty sure the range checking is best done by Hotspot; the compiler doesn't get to see what calls what, Hotspot sees what functions get called by what other functions and is able to do a much better job of that kind of optimisation- it can even optimise into libraries, which the compiler never normally sees at all.
Mind you, this is partly theoretical on my part, I best know about an experimental Sun language called Self which definitely works this way; but Self is what the Hotspot technology is based upon, and there are some wrinkles in Java that may preclude this technique from working quite so well.
Reusing Exceptions is one of those examples that I like to use of how *not* to optimize. It's a basic misuse of an integral part of the Java idiom. Everyone understands how Exceptions work, and how to use the stacktraces to find your error. It's dependable. The poor sucker who's on call when a customer calls because this application keeps crashing takes stacktraces for granted, and is going to be beating his head on his desk after 2 hours trying to figure out what is going on.
So what you are basically saying is 'nobody does it that way' so 'nobody ought to do it that way'?
To begin with, recursion isn't a very efficient process in Java.
It's exactly the same as any Java function call. If you prefer, consider a program with 10 functions that call each other in turn and you realise you need to get information or a signal from the inner one all the way to the outer one; you may have to change hundreds of parts of the code. Using an exception can help localise the changes necessary. That's really what they are for, no?
If you do exit via a reused Exception
If you mean that the user gets to see a reused Exception, then don't do that. You should only use reused exceptions where you know you are going to catch them- that's the whole point, it's purely an internal signalling device that is lightweight from a source code point of view. But you must comment and document it very well because it is uncommon.
If you're writing performance-critical code, you should use iteration, all in one method, instead of recursion,
Yeah, well, you've clearly never written many tree search algorithms. Doing such a thing is often very horrible.
And I still don't like misusing basic Java concepts
It's not a basic Java concept, it's an advanced Java concept, and there is no misuse.
after all, 1 million new Exceptions in 10 seconds is still pretty darn fast when you're only talking about throwing one.
Yes, but that's a best case, the stack size in the benchmark was tiny; the reuse case stays much the same speed whilst the conventional approach slows down. It wouldn't surprise me at all to see a normal throw/catch taking milliseconds on a big system.
Well, thousands of innocents died in the war. Even if tens of thousands died, that is still less than Saddam personally had killed. Even if hundreds of thousands died, that's still less than the people killed in the wars he directly started (i.e., excluding the wars with the U.S.)
True, but not especially relevant. He had already killed lots of innocent people, America killing more innocents doesn't balance the books.
consider what would happen if the U.S. pulled all their troops out of S. Korea and Japan.
Which part of the word 'containment' didn't you understand?
I'm less glad though. Often killing people turns out to be more costly than containment. For example life imprisonment costs less than executing them, and invading Iraq cost something like $70 billion, whereas I doubt that the containment cost anything like that. Sure there are some contracts being thrown around right now, but I wouldn't like to bet that they compensate; and sure we've deposed a very nasty piece of work, but still, it's more expensive, and lots of innocent people died.
The development cost divided by the number of units sold is the absolute minimum price to break even. If the development cost goes too high- you don't break even.
One thing that I've found with hig performance numerical routines is the cost of array lookup (with all of its runtime range checking) is something that can really slow a routine down. I've taken a routine that ran in 500ms and tuned it down to about 80ms (running under the Hotspot compiler).
I'm not totally surprised, but I am a little. Hotspot can often do range checking at compile time and remove the run time checks. However, for it to do that successfully may depend on subtle features of the code, so it won't always succeed. Additionally it may well depend on which version of the jre you are working with.
Frankly, I didn't. I knew that exceptions were expensive, but I didn't know why; and somewhat moronic summaries like yours (no offense, yours was about par for the course in fact) didn't help me understand why.
By the way, I would NOT suggest reusing Exceptions.
I would, where appropriate. I've just benchmarked it on jdk1.4.1 running Windows 2000, and I've found that exceptions run 20x faster if you do that (throwing an exception 1 million times took 10 seconds, reusing took 0.5 seconds on a 650 Mhz Intel- and frankly, a million is a heck of a lot of exceptions!)
What you should strive to do is ensure that, in normal usage of your application, Exceptions will not be thrown (hence your program will be operating at peak speed).
Most of the time speed isn't anything because the program is fast enough. It's only important to run fast where speed is insufficient.
Sounds stupid, but newbies do this kind of thing sometimes as a simple way to bail out when you finish processing early in the method body.
It doesn't sound necessarily stupid. Return or break statements are usually more appropriate though. In some situations (like recursion) an exception is quite possibly the best thing to do; and in that case reusing an exception should be done.
This is covered in the article. You're talking utter nonsense.
* Try not to use synchronized.
Yeah right. This is also covered in the article. Hey, have you read the article?
* Try not to create objects.
Guess not since that was also covered.
Do you know how ridiculous that would be? An object oriented language where you don't create objects? Sure, you can make everything 'static', but what are you going to do about arrays, in Java they are objects? Nearly everything in Java involves objects. Get real!
You should almost never try to not create objects. You may want to, at most, minimise the rate of creation.
* Java still uses a lot more memory and cycles than C/Pascal/C++/etc.
Depending on what you mean by 'a lot more cycles' this may be either true or false. A well designed Java program is a percentage slower. Depending on whether you are spending longer waiting for the program to run or longer writing the program that tells you whether you should be writing in Java or C. But some things like floating point in Java can be as fast as C in some cases, so it's not clearcut.
Generally, if there's a Java program and a C equivalent, you want to use the C equivalent.
Perhaps, but some studies have shown that the C equivalent is twice as expensive to develop, and so may well cost twice as much to buy, but probably isn't twice as good.
Only throw Exceptions in "exceptional" cases, because they will slow things down?
Actually, if you read the article carefully, you find that it says that you should only create exceptions in exceptional cases; that's the slow step, throwing and catching are fairly fast.
So, presumably, if you create a single exception, and keep throwing and catching it, the performance would be much better. Of course the stack data will be wrong, since it will represent the place where it was created, but for many applications that may not matter.
Still, I think it may well be possible to frame it as an NP-complete problem. If n is the length of the program the expected run time certainly goes up faster than polynomial.
Slashdot Mirror
Actually, it's pretty lousy. You have a 2% death rate per flight. That's worse than base jumping (jumping off mountains/cliffs/fixed structures with parachutes, base jumping is often illegal.) About the only thing I know with an equivalent death rate is climbing everest.
Actually, I think he's wrong about the universe dying in a cold universe. The expansion of the universe is accelerating, so as this continues the visible edge of the universe will come closer and closer over time (it's currently about 13 billion light years away, but it's approaching us). Eventually the visible edge will be closer than molecules- at that point all the molecules in the universe fall apart since the electromagnetism will no longer hold them together. Soon after, it will be smaller than nuclei- and then the weak force fails, and bye bye universe.
There's a partial web copy at:
Unix Haters (hint: click on the login cursor)
It's quite dated (Unix 10 years ago, did suck fairly badly in some ways, although not as badly as Windows 95!), and getting exponentially more so. The book was actually fairly humorous, it loses a lot in its translation to the web. The book is well out of print in both senses of the word 'well'.
If the game contained a trading system, even trading virtual items for real money, that's no more illegal or immoral than a shop or an auction.
Just because C++ did something one particular way, doesn't mean it's a good idea. In fact, quite the contrary in my experience.
Still, the vast, vast majority of Moslems condemned Sept 11.
Yeah, that's pretty much so. My understanding is that a bent fiber, no matter how slight the bend, eventually snaps. You can delay the inevitable by making the bend less acute though. By the time you get to a bend radius measured in 10s of cm the lifetime is probably in the multiple decades.
Nasty! So it throws an exception and you don't know where it came from; ever? YUCK .
Its nonsense to change class design because some feature that could be fast happens to be slow.
No, or yes, depending on what you mean here. The right thing to do is to create a new exception type that doesn't fill in the exceptions- for this kind of use.
I figure when I'm being paid to do some work; it's more or less my job to do it the quick/short/lazy way rather than the long way (provided it doesn't do horrible things to the code maintenance or otherwise make the code unnecessarily brittle to changes.)
Doing otherwise does nasty things to the profitability of the company- and I and the rest of the people I'm working with can end up out of a job.
Yes, although a conviction is not determined by whether you did the crime.
The same could be said of you.
No. I live in a civilised part of the world.
2 C2H6O6 + O2 -> 4CO2 + 6H2O
That CO2 could suffocate you, and H2O is harmful by inhalation and is found in all known cancers!
Whatever.
Actually I'm pretty sure the range checking is best done by Hotspot; the compiler doesn't get to see what calls what, Hotspot sees what functions get called by what other functions and is able to do a much better job of that kind of optimisation- it can even optimise into libraries, which the compiler never normally sees at all. Mind you, this is partly theoretical on my part, I best know about an experimental Sun language called Self which definitely works this way; but Self is what the Hotspot technology is based upon, and there are some wrinkles in Java that may preclude this technique from working quite so well.
Which part of the history of 'appeasement' are you unaware of?
The bit that has anything to do with containment at all. Containment is from a position of power/control. Appeasement isn't.
So what you are basically saying is 'nobody does it that way' so 'nobody ought to do it that way'?
To begin with, recursion isn't a very efficient process in Java.
It's exactly the same as any Java function call. If you prefer, consider a program with 10 functions that call each other in turn and you realise you need to get information or a signal from the inner one all the way to the outer one; you may have to change hundreds of parts of the code. Using an exception can help localise the changes necessary. That's really what they are for, no?
If you do exit via a reused Exception
If you mean that the user gets to see a reused Exception, then don't do that. You should only use reused exceptions where you know you are going to catch them- that's the whole point, it's purely an internal signalling device that is lightweight from a source code point of view. But you must comment and document it very well because it is uncommon.
If you're writing performance-critical code, you should use iteration, all in one method, instead of recursion,
Yeah, well, you've clearly never written many tree search algorithms. Doing such a thing is often very horrible.
And I still don't like misusing basic Java concepts
It's not a basic Java concept, it's an advanced Java concept, and there is no misuse.
after all, 1 million new Exceptions in 10 seconds is still pretty darn fast when you're only talking about throwing one.
Yes, but that's a best case, the stack size in the benchmark was tiny; the reuse case stays much the same speed whilst the conventional approach slows down. It wouldn't surprise me at all to see a normal throw/catch taking milliseconds on a big system.
True, but not especially relevant. He had already killed lots of innocent people, America killing more innocents doesn't balance the books.
consider what would happen if the U.S. pulled all their troops out of S. Korea and Japan.
Which part of the word 'containment' didn't you understand?
In that case, that's all your life is worth too.
I'm less glad though. Often killing people turns out to be more costly than containment. For example life imprisonment costs less than executing them, and invading Iraq cost something like $70 billion, whereas I doubt that the containment cost anything like that. Sure there are some contracts being thrown around right now, but I wouldn't like to bet that they compensate; and sure we've deposed a very nasty piece of work, but still, it's more expensive, and lots of innocent people died.
The development cost divided by the number of units sold is the absolute minimum price to break even. If the development cost goes too high- you don't break even.
I'm not totally surprised, but I am a little. Hotspot can often do range checking at compile time and remove the run time checks. However, for it to do that successfully may depend on subtle features of the code, so it won't always succeed. Additionally it may well depend on which version of the jre you are working with.
Frankly, I didn't. I knew that exceptions were expensive, but I didn't know why; and somewhat moronic summaries like yours (no offense, yours was about par for the course in fact) didn't help me understand why.
By the way, I would NOT suggest reusing Exceptions.
I would, where appropriate. I've just benchmarked it on jdk1.4.1 running Windows 2000, and I've found that exceptions run 20x faster if you do that (throwing an exception 1 million times took 10 seconds, reusing took 0.5 seconds on a 650 Mhz Intel- and frankly, a million is a heck of a lot of exceptions!)
What you should strive to do is ensure that, in normal usage of your application, Exceptions will not be thrown (hence your program will be operating at peak speed).
Most of the time speed isn't anything because the program is fast enough. It's only important to run fast where speed is insufficient.
Sounds stupid, but newbies do this kind of thing sometimes as a simple way to bail out when you finish processing early in the method body.
It doesn't sound necessarily stupid. Return or break statements are usually more appropriate though. In some situations (like recursion) an exception is quite possibly the best thing to do; and in that case reusing an exception should be done.
This is covered in the article. You're talking utter nonsense.
* Try not to use synchronized.
Yeah right. This is also covered in the article. Hey, have you read the article?
* Try not to create objects.
Guess not since that was also covered.
Do you know how ridiculous that would be? An object oriented language where you don't create objects? Sure, you can make everything 'static', but what are you going to do about arrays, in Java they are objects? Nearly everything in Java involves objects. Get real!
You should almost never try to not create objects. You may want to, at most, minimise the rate of creation.
Depending on what you mean by 'a lot more cycles' this may be either true or false. A well designed Java program is a percentage slower. Depending on whether you are spending longer waiting for the program to run or longer writing the program that tells you whether you should be writing in Java or C. But some things like floating point in Java can be as fast as C in some cases, so it's not clearcut.
Generally, if there's a Java program and a C equivalent, you want to use the C equivalent.
Perhaps, but some studies have shown that the C equivalent is twice as expensive to develop, and so may well cost twice as much to buy, but probably isn't twice as good.
Actually, if you read the article carefully, you find that it says that you should only create exceptions in exceptional cases; that's the slow step, throwing and catching are fairly fast.
So, presumably, if you create a single exception, and keep throwing and catching it, the performance would be much better. Of course the stack data will be wrong, since it will represent the place where it was created, but for many applications that may not matter.
Still, I think it may well be possible to frame it as an NP-complete problem. If n is the length of the program the expected run time certainly goes up faster than polynomial.