Java Performance Urban Legends 632
An anonymous reader writes "Urban legends are kind of like mind viruses; even though we know they are probably not true, we often can't resist the urge to retell them (and thus infect other gullible "hosts") because they make for such good storytelling. Most urban legends have some basis in fact, which only makes them harder to stamp out. Unfortunately, many pointers and tips about Java performance tuning are a lot like urban legends -- someone, somewhere, passes on a "tip" that has (or had) some basis in fact, but through its continued retelling, has lost what truth it once contained. This article examines some of these urban performance legends and sets the record straight."
Memes (Score:1, Insightful)
Are you new here? Usually people call this kind of thing a meme.
The best tip (Score:5, Insightful)
"Save optimizations for situations where performance improvements are actually needed, and employ optimizations that will make a measurable difference."
Re:Java for Applications.... (Score:2, Insightful)
SWT [eclipse.org] rules!
Re:It doesn't help... (Score:5, Insightful)
One day, someone is going to come along with a really f'ing amazing language. Everyone will be talking about how great it is. And if you are lucky, it might have half the features that Lisp has had for ages.
Absolut no content (Score:2, Insightful)
And about the strings example:
If you want't to prove that the Immutable string class is not slow the right way to do it is to make a program that make a lot of string operations and then compare the speed with one of the non Immutable string classes for java that exists.
I really wish that the slashdot editors would read the stories and dismiss the one widtout any information.
(Yes I know, the slashcode is free, so I could just make my own news-site but life is to short, and the studie take to much time.
Antidote (Score:4, Insightful)
Here's a bit of an antidote: Why Java will always be slower than C++ [jelovic.com]
Re:To what extent does this exist in other languag (Score:2, Insightful)
Good advice. People sometimes seem to want to solve the problem before knowing what the problem statement is. While their actions may not degrade performance significantly, they often times do not help.
I've learned over time that everything is relative. There is no cut and dried right and wrong in a lot of cases, but degrees of both. The real answer depends on your need, and not all needs are the same.
kind of right, and that's a problem (Score:3, Insightful)
But that's not really a good thing. Sun pushed on the JIT on the theory that that would address performance problems. It didn't. The Perl and Python runtimes are much slower than Java's, but Perl and Python applications generally start up much faster and are considerably more responsive.
Java is as sluggish as ever, and more bloated than it has ever been. What is really responsible for Java's poor performance for real-world applications is its class loading, memory footprint, and just plain awful library design and implementation.
Re:Java's memory usage (Score:3, Insightful)
Profile your software, don't guess (Score:2, Insightful)
Bullshit (Score:3, Insightful)
Let's take them one by one:
<br>
<LI> Final methods and classes - when you call a final method from the same class you save a lookup in the virtual method table (there is no doubt about what method is going to be called, as it couldn't have been overwritten in a descendent), and furthermore you can inline that method. On a "stupid" JVM (read: from Sun) you won't see any difference, on an optimized one you will.
<LI> Synchronization can become a bottleneck on SMP systems, because it implies cache synchronization (exiting a synchronized block
is a memory barrier) - you clearly aren't going to see it on a single processor. But not using synchronization is just as bad (you should use synchronization with <b>all</b> variables that are shared, because you do want memory barriers for correctness)
<LI> Immutable objects - this one clearly depends on the garbage collector that you use.
<p>
Conclusion: the performance of these tricks depend on two things - your JVM and Amdahl's law (how often are these improvements going to manifest themselves)
<p>
Enough about the things Java can never fix. (Score:5, Insightful)
JNI is the NATIVE INTERFACE. For those that don't already know, that's the interface to the underlying operating system. If the OS misbehaves, hiccups, or is inconsistent, when did it become JAVA's responsibility to clean up? When somebody decided that JAVA was getting a black eye because OS call foo(bar) was crashing the application, or better yet didn't behave exactly like foo(bar) on every OS that provides the JVM.
Don't like AWT? Well mabye that's because it's built on top of JNI. Enough said.
Don't like Swing? Well you'd better like AWT. If you don't want the OS to do your GUI work and you don't want the JVM to do your GUI work, mabye you should just get a dry erase marker. You can draw the boxes you need on the screen provided you use a tissue between display updates.
String requres no more attention than any other bit of JAVA code. If you create dozens of objects for the sole purpose of garbage collection, you either just learned JAVA, you're unaware of what you're doing, or you don't care.
And about garbage collection. JAVA's garbage collection may not be your cup of tea, but neither are the memory leaks that are still being cleaned up in systems that lack automatic garbage collection.
So pick your posion. If JAVA isn't perfect, that dosen't make it horrible. JAVA is a good language by most standards, but be honest by stating that it isn't good by your standards.
My biggest reason for liking JAVA is that it forces people to stop writing bad C code. Which is exactly what it was designed to do.
Re:Enough about the things Java can never fix. (Score:2, Insightful)
Yeah but... (Score:5, Insightful)
However, what I really dig is the library. Sockets, Strings, half a billion data structures, numeric and currency formatting, Internationalization and Localiztion support....
And there's always the JNI if I need to optimize in C.
Not to mention servlets, JSP's and JDBC.
You gotta' admid that this is all great stuff. So for certain applications (specially on the server) the benefits of the library far outweigh the performance problems of the sandbox.
Yeah, C++ has a great library too. But the Java library is so damned easy to use.
Seductive the dark side is.....
Re:Java is Slow (Score:1, Insightful)
Because those versions of BASIC were all, essentially, interpreted.
Java is essentially an interpreted language, despite JITs and JNIs and whatever.
Interpreted languages are slow. That's why no one writes full-blown applications in BASH.
Re:Java's memory usage (Score:5, Insightful)
>efficient?
Well, java applications tend to use a whole lot of memory compared to C++, because of the way objects are allocated, and because there is no control over the details of allocation available to the programmer. Java Objects tend to be pretty heavy, partly because every Object carries a virtual table (to implement polymorphism, reflection, etc.) and also because every Object has the overhead required for the thread synchronization model.
As to whether or not it is "efficient", it depends on your point of view. For some applications, the java memory model is very efficient. Java goes to great lengths to ensure coherence among unsynchronized reads and writes in multiprocessor systems, and it must accomplish this via completely abstract means. Platform independence comes with a price, and a big part of that price is that high level optimizations become difficult or impossible to implement. JIT's and native libraries may help, but, there is still a hugely complex problem in exposing any sort of high level control of those things to the programmer. That is, in my opinion, the main reason that it is not fair to compare Java performance to C++ performance. It is not an apples-to-apples comparison. I think it would be reasonable to compare a transaction system written say, in J2EE under an app server, to say, a C++ transaction system running under an ORB. I think you will find that Java compares favorably in that context, and is simpler to write and maintain. I believe that makes it an excellent choice for business software.
If your model did not require threads and locks, for instance, you could do away with much of the complexity.
There is a whole heck of a lot going on under the hood to enable concurrent processing. You write your code as if it will execute sequentially, but there are many situations where operations will be interleaved, optimized to execute out-of-order (or even optimized away entirely).
The java implementation is much more concerned with Visibility, Atomicity, and Ordering, than it is with raw performance. If you really want to learn how it works, the specification is not a difficult read. Most of the details about memory are here:
http://java.sun.com/docs/books/jls/second_editi
Bigger synchronization myths (Score:5, Insightful)
However, the article perpetuates another myth: "Synchronization should be easy. The more things you synchronize, the better off you are."
My hard experience says otherwise. First off, making multithreaded programs work correctly is very hard. Therefore, multiple threads should be avoided if at all possible. You can avoid a lot of these problems in many cases if you use a function like "select()" in a single-threaded program (which, IIRC, Java unfortunately doesn't support). Even though it looks harder to program, it ends up being easier to debug.
However, sometimes you just can't avoid threads. IMHO, adding "synchronize" as a language keword and encouraging easy creation of threads was a mistake. That doesn't begin to solve your problems. For example, it does nothing to help you avoid deadlocks. In fact, sprinkling synchronized blocks around your program is a recipe for deadlocks and unexpected timing-dependent buggy behavior.
If you must use multiple threads, there should be one main thread that runs almost all of the program's logic, and a set of highly constrained, carefully controlled worker threads. These threads should not interact with any other (mutable) data structures in the program. Ideally, there should be at most two synchronization points in the program: a work queue and a results queue. The elements of these queues should package up all of the state needed for a worker thread to solve a piece of a problem or deliver its results.
With an approach like this that has minimal synchronization, there's no need to add a keyword to the language or put synchronization into many library container classes. And of course, performance is hardly an issue at all when you only synchronize twice per worker thread run.
Why do poor coders have tunnel vision? (Score:5, Insightful)
Yes, if I need speed, I use C, the same as anyone else. If I am writing a Web application, I use Java. That's an area where Java excels. And maybe I'll get lucky enough to be able to code a project in Assembly or Lisp, who knows? Programming does not follow the "jack of all trades, expert at none" theory. General concepts map well across the spectrum.
I find it discouraging that there are so many programmers who only want to learn as much about their job, as to merely be good enough . Don't they feel any pride, or any desire to excel at something?
Coders who can only handle one language should be paid minimum wage; that is all they are worth. That is because it is neither the language nor the implementation that is important. It is the knowledge of how to program which will ensure your career and pay your bills.
a lot (Score:5, Insightful)
There's quite a bit of other stuff like this out there as well.
Re:Performance is ok, but memory footprint... (Score:1, Insightful)
I had a funny time discovering this one out for myself when a java program I launched used 2x more than my physical memory and swap space combined.
Of course you may ask me why I was running an enterprise application on a 486, but that's another story...
Re:Antidote (Score:5, Insightful)
People dealing with time series data will use a time class. Anybody using these will definitely hate trading a zero-time stack allocation for a constant-time heap allocation. Put that in a loop and that becomes O (n) vs. zero. Add another loop and you get O (n^2) vs. again, zero.
What? A constant time operation in an 'n' loop is O(n), but then again, the loop is O(n) to start with. Add another loop and you get O(n^2) versus O(n^2). The constant of proportionality has changed, but that's all. If you were using C++, you'd probably call a constructor and possibly destructor anyway; so the difference is not nearly as much as you'd expect; and java heap allocation is only about 3 instructions anyway on a decent VM. This article is total junk.
Re:Java's memory usage (Score:2, Insightful)
1. Managing the ref counts costs.
2. You can hide the costs of GC by doing it when idle or on another processor; not so with ref counts.
3. Ref counts are prone to memory leaks when you have ref cycles. This is especially bad for long-running (server/embedded) apps.
However, Java GCs do seem to cause problems for many programmers. I don't know if the problems are unavoidable or just caused by crappy JVM implementations.
No proof and +5 Insightful? (Score:0, Insightful)
Re:Yeah but... (Score:5, Insightful)
Re:Antidote (Score:3, Insightful)
Java does virtual method inlining. That, alone, makes it potentially faster than C++. A slightly more intelligent garbage collector designed to decrease page-faults later, and presto, C++ is the slow language.
[Note that Garbage Collection can't scale very well on multiple CPU machines, so Java still won't be the be-all-and-end-all language unless it divides its objects into seperate "memory pools" a la the Apache Portable Runtime, and GCs them all seperately and scaleably.]
Even once every test shows that Java is faster - and that is almost certain to happen, because ahead-of-time compilers simply can't compete with runtime-compilers (in principle), people won't stop *using* C++, because they won't believe that Java could ever be fast. But Java is definately the way forward for object-orientated languages.
You don't have to like OO, of course. And Java will never be as fast as C. But if you like OO, you have to like Java.
The reason people think Java is slow is generally due to Swing. Swing is just a piss-poor kind of UI framework. If it was compiled with an ahead-of-time compiler, it would just be worse. You shouldn't judge a language by one of its libraries, however.
(I am not blinded by the holy light of Sun - there are legitamate complaints you could make against Java, usually to do with memory. The article you linked does not invoke any one of them)
-Emlyn
Java not always slower (Score:5, Insightful)
Try writing a simple recursive Fibonacci number calculator in both C++ and Java. The Java one is faster, when using a JIT enabled JVM. Of course, that is a contrived example, but it shows that just-in-time compiling can be faster.
Re:Java is Slow (Score:4, Insightful)
People don't generally write one-off small apps they intend to run hundreds of times a day in java. That's not what it's designed to do.
If you want to compare performance, do something real-like and have it run once in your two or so languages to get a base, and then run them a few thousand times. Something more like this:
http://www.bagley.org/~doug/shootout/
Re:Java is slow (Score:3, Insightful)
There is a difference between using up all your memory and running out of memory. Java maxes out the memory that it's allowed to take in the circumstances I was talking about.
Suppose you have a tight loop that creates a few objects and then disposes of them. Further suppose that loop spikes the CPU, as would be the case for something under constant load or with a lot of data to process. Then you will be creating objects faster than the GC can get rid of them, because the GC is a lower priority than your main thread, which is doing the important stuff. GC is, by its nature, a lower priority task.
But sometimes it just needs to be higher priority. In the above case, the program will take up all the memory it's allowed. As you suggested elsewhere, you could simply not allow it to take up that much memory. But there might be valid cases where it needs that much memory. In these cases, virtual memory is the sad reality, but correct action is better than no action. However, you do not want all your cases to be this degenerate. So you are forced to decide between simple failure when much memory is needed, or maxing out a large portion of memory in all cases. I shouldn't have to make that choice.
As others have suggested, I could tweak the GC to deallocate faster. But this is a flaw. Java should make things simpler, not more difficult. Telling the computer when I'm done with an object is a simpler solution (to me, anyway) than having to tweak runtime parameters.
If I couldn't trust someone to use new and delete correctly, I wouldn't trust them to do much at all for me. Yes, there are many programmers that mess things up with these operators, but they aren't very good programmers. If you can't use new and delete or free and malloc correctly, then there's probably a lot of other things you can't do well either. Memory management is rather fundamental to computer science.
Now, the transparent memory access in C++ is certainly dangerous. But I'm not talking about direct access to memory. I'm talking about garbage collection on demand.
For example, I do not see how things would become much more dangerous in Java if you added a delete operator to complement the new operator. The operator would have the semantics that meant "delete, now". If you tried to access a deleted object, it would throw an exception. The level of danger afforded by such a feature would be vastly outweighed by the advantages wrought.
Re:Antidote (Score:3, Insightful)
errr...
Saying "Java will always be slower than C++" is like saying that there will always be less graduate students than undergraduates. Java and C++ live in the same Von Neumann-ian world, but C++ is allowed to muck with pointers, and Java isn't. Moreover Java has garbage collection.
However, I dare say that the time that a programmer saves by not mucking around with pointers is far more valuable than the time saved by typical C++ optimization. This may not hold true in performance-critical domains (like game programming), but for the vast majority of programming problems, it's fine.
If performance was always critical, why do any of us use Perl or Python? To save time.
Hypocritical (Score:2, Insightful)
Re:Antidote (Score:5, Insightful)
My favorite was the cast issue. He fails to recognize that the code he is talking about is run once, then it is a static cast just like most people use in C++. Something that must by dynamically casted at runtime, on the other hand, will be much faster in Java since it doesn't have to figure out the casting for an object every time you cast. It basically does it once, then it will be able to cast any object of the same time to the same casted type as before.
It's complete idiocy by a person who hasn't spent any significant time using Java.
If you want to critisize Java you must:
A: target memory usage, site a specific API and why in your OPINION you don't like it, or target startup time.
B: have not used C++ techniques of optimization on Java
C: have tried the latest JVM.
D: have checked the bug parade, and found that the issue you are talking about is not currently being fixed or has been in the bug parade for a very long time.
If you don't follow all those, then you are really just taking pot shots at a system that works quite well for a LOT of people. I've never met anyone that didn't like Java after they played with it for a while (except back before 1.3).
There is a SSH server written in Java now that supports all the features that OpenSSh does... I think I'm going to give it a try... no more CRC buffer overflows for me.
Re:Times change (Score:3, Insightful)
I thought the rest of your comment was insightful, but .Net is a very new technology that, for sure, will improve markedly in terms of performance in the future. It is unfair to compare pre-release first version .Net with a mature implementation of Java. (I am a MS hater, but let's be fair.)
Sure I remember... (Score:2, Insightful)
I used to be the best damn VB programmer there was until around version 6.0. Well, maybe not the best, but I sure did some cool stuff with VB. I got started years ago with GWBASIC too. IBM made one of the first PC compilers for BASIC called "BASIC Compilers 1.0 and 2.0" This was the pre-mouse era, 1985-87'ish days. For lack of a good editor, I used the GWBASIC interface. When we finally compiled with the 1.0 compiler, the code ran a good bit faster. Then, we got the 2.0 compiler. Oh god how slowly our code ran with 2.0. I don't know what happened with 2.0 but it just didn't cut it. We ended up selling our program compiled with the 1.0 compiler.
Later, around 1988, we got our hands on the first Microsoft QuickBasic compilers. The compiled code then ran like lightning! We found that the QuickBASIC's used the new P-code interpreter. I used QuickBASIC quite a bit. Later, in the early 90's, I changed to VB around version 2.0. VB was quite nimble for program size and execution speed. But when we got version 4.0, it would compile to native code. This was the best performance I ever got out of VB before I realized...hey, the language just isn't giving me what I wanted...eg...smaller size, and faster speed.
Actually, I had been programming in C since around 1989. And, the more I used C, the more skilled I got at writing C code. The break point came with VB 6.0. I just couldn't justify using VB anymore as it wasn't a good environment for writing command line system administration programs. I was entering into systems administration/programming as my main job, so my code needed to run fast, lean, and mean.
When the Java phenomenon hit, I saw clearly from my VB experience that this just wasn't going to be a pretty scene. On the one hand, you had plenty of newbies who really didn't know anything about programming spouting the Java mantra. And, with the Internet, it seemed the entire world was going Java. The two bubbles of Java and the Internet seemed to go hand and hand.
The state of Java now is pure and simply...just bloat. For example, just download and run Morpheus. The thing is written in Java, and for just a simple application, uses 54 Meg. What the heck, 54 Meg!!!??? And, this C# stuff that Microsoft is producing just isn't any better. A simple C# hello world program uses 11 Meg!
I just can't use applications that take seconds to minutes to load up, then use up all my memory, then run slow as Christmas. I'm a systems programmer, I write applications that load, do what they need to do as fast as possible, then completely unload and get out of the way. My apps have to run background'ed so they don't interfere with the users. I don't want my memory used for program space, it's supposed to be used for data space!
You might say that memory, disk, and GHz are cheap now. Well my response is...so are your coding skillz! The one thing I've realized over the years is that the more time you spend programming in these high level languages, the more real experience you lose where you could be coding smaller and more efficiently nearer to the core. I'm trying to say that maybe I wasted a good bit of time in VB when I shouldn't have. The same goes for the Java guys. We had a great programming language called C, and C++ that got pushed to the back-burner because of some people who decided that garbage collection and VM's were a "good thing". Well, maybe they are, but at the expense of expertise in programming? I mean come on, if you can't handle pointers, can you really call yourself a programmer?
I'm so tired of programming environments that keep people from shooting themselves in the foot, or coddle beginning coders. Programming is a skill and an art. It is a good bit like architectural design. Java and VB just turn things into manufactured housing. Do you "want" to live in a double-wide home, or one that was designed to be functional, strong, and beautiful?
I suppose I'm being too hard on everyone here. Heck, I still use VB
Re:The article is wrong (Score:2, Insightful)
Re:Sure I remember... (Score:5, Insightful)
Not all programs have the same requirements. In most cases developer time is much more valuable than CPU time.
Stay as close to the CPU core as possible, but far enough away to be effective. C and C++ are the only languages that accomplish this role.
Ridiculous. Most good programming techniques are independent of language. If you can't develop effectively in anything but C or C++, then your "skillz" could use some work.
Think before you code.
Yes. Think whether the performance gained by using a low-level language is actually significant, and if so whether it offsets the increased development time and greater risk of uncontrolled failures (e.g. exploitable buffer overruns).
C is a fine language, and is often necessary. But it's a premature optimization to insist on always using it because of nebulous performance concerns.
Re:Antidote (Score:3, Insightful)
For example, some implementations of malloc() have quite a noticable overhead, while allocating an object with a generational gc has an overhead of increasing one pointer. Additionally, you get better locality, and the order in which space is reclaimed is better suited for the real usage pattern than what human programmers tend to come up with, to the point that some objects may never be reclaimed, because it just wouldn't pay off enough.
Re:a lot (Score:3, Insightful)
Re:Bullshit (Score:3, Insightful)
You don't appear to know much about synchronization in Java.
Take your first example. Synchronized methods obtain locks on the object this (or the Class object in the case of static methods), not on the variable referenced therein. If bar() is called while foo() is executing, bar() will not begin executing until foo() finishes. If this were the only synchronized code in a program, it would not be possible for that program to deadlock. However, Java does not find or break deadlocks.
Your second example is, as you say, a horrible use of synchronization. However, the correct way to be more fine-grained is to place the println statement in a synchronized block.
You are correct that using synchronization requires you to make sure your code doesn't deadlock, and to consider the reduction in concurrency. However, that really has little to do with the article. Nobody who seriously complains about Java's performance does so because it is possible to use synchronization improperly. This is a programmer error, not a language issue. The article addresses the myth that Java's implementation of locking is horrendously slow.
Simple code is more future-proof (Score:3, Insightful)
Re:Sure I remember... (Score:3, Insightful)
Java is used for writing large-scale backend enterprise applications, not small command-line utilities. Nobody is suggesting it as a replacement for perl. With the programs Java is used for, startup time is irrelevant (since it's only started once) and a 50 meg overhead is insignificant.
We had a great programming language called C, and C++ that got pushed to the back-burner because of some people who decided that garbage collection and VM's were a "good thing".
C++ wasn't a "great" programming language, it was a syntactic disaster. C is decent for systems programming but still has its defects.
Well, maybe they are, but at the expense of expertise in programming? I'm so tired of programming environments that keep people from shooting themselves in the foot, or coddle beginning coders.
This is one attitude that has to be guarded against. Unfortunately, there is a class of people who wrongly call themselves "real programmers." They try to prove their machismo by purposefully avoiding modern techniques, and by doing things in a primitive and difficult way. These programmers overestimate their skills, because they produce unreadable, unportable, bizarre, buggy code that has marginal or nonexistent performance benefits.
Manual manipulation of pointers causes a 50% increase in bug count, and that's when they're being used by experienced C programmers. When C programmers can write large-scale applications that have no pointer bugs at all, right from the start, then I'll favor letting the "real" programmers have free reign.
I mean come on, if you can't handle pointers, can you really call yourself a programmer?
Programming exists to accomplish real-world tasks while meeting abstract design criteria, like code readability. It doesn't exist to dereference pointers, twiddle bits, or shift things around in Unions.
your weird proselytic sig (Score:2, Insightful)
Jesus of Nazareth did not die so we could enjoy eggs and chocolate bunnies!
Are you sure? Christians enjoy eggs and chocoloate bunnies because despite the attempts of many clueless religious nuts, Christianity did not succeed in stamping out the natural human instinct for enjoying life, in the form of festivals and celebrations in which everyone can share - not just those who believe that their life is controlled by an imaginary being.
Celebrations of renewal and fertility in springtime, involving common symbols such as eggs and rabbits, were widespread before Christianity came along, and they continue today. In one sense, your sig is accurate, in that Jesus of Nazareth has nothing to do with it, other than the fact that the churches that exploit his name co-opted other traditions as part of their relentless assimilation of followers. But in another sense, the sig is wrong, since based on his record, I suspect Jesus of Nazareth would have no problem with people enjoying eggs and chocolate bunnies, even - and perhaps especially - on the anniversary of his death.
Re:Yeah but... (Score:3, Insightful)
This is another false statement. Unless you pass more bytes than the buffer really holds in the 'recv' function, you don't have to bounds-check anything. Because the operating system makes sure the received data fit on the given buffer. So, BSD sockets don't require bounds checking, but what you do with the data after that may do.
He's saying that it's impossible to write buffer overflow code in java. Clearly, not only is it possible to do so in C, it's rather common. This is a language advantage, not a library advantage.
Re:The article is wrong (Score:2, Insightful)
In particular, if you use a+b on String objects, the compiler will translate to use of a StringBuffer, even though that StringBuffer is manifestly not accessible from any other thread. I don't know if the JVM will optimize away the synchronization -- if it does, the analysis to allow it to do so is an overhead anyway.
The problems with StringBuffer are varied:
1. It is overcomplicated because it uses reference counting to avoid a single object allocation.
2. It guarantees thread safety even though that is not required for most of its uses.
3. The thread safety protects the integrity of the StringBuffer, but is not enough for most code that could use a StringBuffer from multiple threads: th e granularity of the locking is too fine. This is the same flaw that lead to the introduction of the unsynchronized collection classes (such as ArrayList to replace most uses of Vector).
4. It is overkill for the uses the Java compiler makes of it in performing string concatenation, and a performance penalty is paid.
One other interesting thing to note is that my UnsychronizedStringBuffer did not have a default constructor. This forced developers to specify an estimate for the size of the buffer, and so avoided most reallocations -- another performance win, just by restricting an interface.
JBuilder makes a case for interactive performance (Score:2, Insightful)
Bad interactive java is easy to write, just like bad MFC applications are easy to write.
A few from C++ (Score:5, Insightful)
The C++ world is full of myths about what does and doesn't enhance performance. Amongst my favourites...
In each of these cases, there is some overhead involved if you actually use the language feature, but generally not otherwise with any recent compiler. However, those overheads are usually less than hand-crafting the equivalent functionality (e.g., long jumps, function look-up tables a la C) would incur. Furthermore, if you actually understand the implications of these features, you can keep the overhead way down. The next time I see someone criticise templates for code bloat, and then demonstrate in the next post that they've never come across templated wrappers for generic base classes, I'm going to have to lecture them. }:-)
On the flip side...
Most of these get much more credit than they deserve. The first is true often, but not always: it sometimes shafts the optimiser in many compilers. The second is not true with any recent compiler. The third is true sometimes, but not nearly as often as you might expect: optimisers miss many of the apparent (to humans) possibilities anyway, and spot some of the others with or without a const there.
As always, the rule of thumb is to write correct, maintainable code first, and then to use compiler-specific, profiler-induced hackery where (and only where) required. Whether you're writing a database or a graphic engine, this is pretty much always good advice.
Re:Sure I remember... (Score:2, Insightful)
Great. Another "back-in-my-day" ranter....
The state of Java now is pure and simply...just bloat.Since you indicate yourself that you believe only in the Holy Grail of C and C++ and will not touch anything else, I am going to suggest to you that you are not in any real position to judge.
You might say that memory, disk, and GHz are cheap now.Rather, I'd say that the demands to which you code are no more universal than your insights into the absolute and relative value of Java (or any other language).
Well my response is...so are your coding skillz!I have my opinion of people who deliberately replace "s"es with "z"s and think this says good things about them. As for your skills, if you truly think that coding in C is the only way to write "fast" programs and that everybody who does not code in C must by consequence be a poor developer, I am already underwhelmed. Even without having seen any of your work. And I assure you that your standing as a programmer from the stone age does nothing to alleviate this.
The one thing I've realized over the years is that the more time you spend programming in these high level languages, the more real experience you lose where you could be coding smaller and more efficiently nearer to the core.Your "experience" is fa from universal, I assure you. What you are seeing is a lack of experience and possibly the adverse effects of what passes for computing science education in a lot of places -- it is not related absolutely to the use of any particular language per se, nor does the use of any particular language in and of itself mean that you cannot learn that which you consider to be "hardcore" programming (for what that's worth). Much though I appreciate Edsger Dijkstra's wit, the assertion that using any particular language must necessarily taint a person forever is nonsense.
Well, maybe they are, but at the expense of expertise in programming?Don't confuse "expertise in programming" with "expertise in one particular language". The best programs arise from competent design and following implementation in a language, not from design towards a specific language from the beginning.
I mean come on, if you can't handle pointers, can you really call yourself a programmer?There's an unofficial motto at the CS department at my alma mater: "the best CS engineers are made from those people who come here never having seen a computer in their entire lives". Being a "programmer" doesn't live in having a reflex that causes you to combine the Shift-key and the 8-key, but in being able to grasp the concepts and apply them to the situation you find.
Programming is a skill and an art. It is a good bit like architectural design.The first of those statements is true (and that is an enormously bad thing, make no mistake), the second is patently not. If architecture was like programming, we'd clap all architects in jail because their buildings would collapse so often. Programming is indeed an art -- there are so few people who do it well. Programming on the other hand is nowhere near mature enough to be called anything as well-founded and scientifically based as architecture. We have nowhere near the level of sophistication and scientific backing, let alone the level of reliable education that supports architecture, to pat ourselves on the back to that extent.
Do you "want" to live in a double-wide home, or one that was designed to be functional, strong, and beautiful?The latter. Thank god I need not rely on a programmer to build it for me.
Re:A few from C++ (Score:3, Insightful)
Well, yes, but then they're not really exceptional, are they? Exceptions aren't intended to replace break or if.
The point here is that just having exceptions in the language does not mean all your code runs slower. Contrary to oft-quoted opinion, the zero overhead principle does apply here with modern compilers.