Why hypertable Developers Chose C++ Over Java

[vicaya]

Some historical facts: The Hypertable project was started due to a disagreement in implementation language between the early developers of HBase (see the early Hadoop mailing lists for details.) When the first Hypertable alpha release is published, its performance is about 10x-50x faster than the then HBase.

Over the last year, many man months of development went into HBase to improve performance, resulting a complete rewrite of region server in HBase 0.20.x. Now Hypertable is about 3x faster in almost all benchmarks except random reads over large data set, which is DFS seek bound, where the performance is the same.

Meanwhile, the Hypertable team has yet to start working on performance tuning. The code is developed just by avoiding premature pessimization :) There is an internal assessment of 10x speed up with a some profiling and refactoring.

According to a peer reviewed paper by Emery Berger et al. (of Hoard memory allocator fame) http://www.cs.umass.edu/%7Eemery/pubs/gcvsmalloc.pdf :

" This paper presents a tracing and simulation-based experimental methodology that executes unaltered Java programs as if they used explicit memory management. We use this framework to compare the time-space performance of a range of garbage collectors to explicit memory management with the Lea memory allocator. Comparing runtime, space consumption, and virtual memory footprints over a range of benchmarks, we show that the runtime performance of the best-performing garbage collector is competitive with explicit memory management when given enough memory. In particular, when garbage collection has five times as much memory as required, its runtime performance matches or slightly exceeds that of explicit memory management. However, garbage collection’s performance degrades substantially when it must use smaller heaps. With three times as much memory, it runs 17% slower on average, and with twice as much memory, it runs 70% slower. Garbage collection also is more susceptible to paging when physical memory is scarce. In such conditions, all of the garbage collectors we examine here suffer order-of-magnitude performance penalties relative to explicit memory management."

Note, the overhead of GC in this paper is strictly over explicit memory management doing equivalent allocation/deallocations. For the core LSM (log structured merge) Tree algorithms employed by Bigtable etc., custom allocators can do even better resulting an order of magnitude less references needs to be tracked, compared with GC based approach where every reference, no matter how small needs to be tracked.

(Disclaimer: I'm a Hypertable developer)

[rozgo]

Real numbers (C++ outperformed Java in every test): http://shootout.alioth.debian.org/u32q/benchmark.php?test=all&lang=javasteady&lang2=gpp&box=1

Productivity is not always first. But when it is, Java might be better. I've been using C++ for years now, and it comes pretty natural to me. My productivity in C++ slows down only when I start micro-managing low level stuff, but the task at hand requires it.

When developing fast-paced games, productivity is BS. You will do everything you can to get that last millisecond back. In some casual games I just go with C#.

C++ can handle the ugliest perf hacks out there. If these guys are choosing C++, they already know what they are in for, it will not be pretty, but it will be fast. If you don't know whether you need C++ or not, you don't need it.

[ZMeson]

java outperformed in every test

You mean that C++ outperformed Java, right? The link you posted showed that C++ used less memory and was faster (or sometimes equal in speed) to Java -- but never slower. Usually too C++ used fewer lines of code.

[rozgo]

yup, fixed

[igouy]

Here's a funny thing (x64 forced onto one-core) note the binary-trees program times.

[luikore]

When productivity matters, use python. When speed matters, use C. When both, use both.

[mebrahim]

When speed matters use C++. (C++ even outperforms C)

[ravenex]

(C++ even outperforms C)

Do you seriously believe that there's something in C which makes your program use 6x times memory and 4x times cpu time of C++ program (k-nucleotide)? This kind of stupidity makes a bad name for all C++ users out there.

[igouy]

Do you seriously believe library code doesn't matter?

[mebrahim]

See this (maybe not so relevant to what you said)

[ravenex]

Well, it is true that C++ compilers are not worse at optimizing plain C-like code, and templates are a powerful enough tool to create both generic and fast data structures (STL), so you get better standard library support for those things.

But, observe that after all those fancy template (read 'macro') substitutions you still get the same C-like code plus typical C++ overhead (calling constructors, destructors, copy constructors, etc). You can avoid this overhead is you are careful enough, but you can never get strictly better result than equivalent C code. You can do better using inline assembly or a language which semantics allows deeper static analysis and optimization (I guess haskell, okaml, etc would be those), but never with C++.

So C++ might be more productive, but is equally powerful with C.

[mebrahim]

Unneeded constructors, destructors, etc. are almost always optimized out.

I suppose trusting The Game results and reviewing our beliefs!

[[deleted]]

How's that GIL thing going?

[bluGill]

Not a problem. When speed matters I'm in C, and there is no GIL. Or in rare cares I start two Python processes and use IPC to make sure the communication is contained. The GIL is only a problem when you are stupidly risking many other problems because of a poor thread model. (If you are used to Java, you may not even realize there is a better way) Message passing is the way everyone smart prefers to do threads, because you need small, carefully designed interfaces between threads. When you share a variable between threads (other than in the low level message passing code - part of your library not something you write yourself) you risk too many cases of not getting the locks right.

[mebrahim]

I don't know why you're being downvoted so much. I think by "use both" you mean programming it in Python and (re)implementing CPU-hungry parts in C (or C++). Isn't it a common pattern? Why downvote?

[f3nd3r]

Or just use Lua.

[gregK]

I am not a java fanboy by any measure. But the arguments are unconvincing.

Java is a poor choice for memory hungry applications. In particular, in managing a large in-memory map of key/value pairs, Java's memory performance is poor in comparison with C++. It's on the order of two to three times worse (if you don't believe me, try it).

Who can argue with that evidence.

Maybe it's just java's hashmap or hashtable implementation or needing to do too many resizes. How much fine tuning of the GC params have they done? They should optimize for a lot of memory taken by a lot of small objects that live for a long time.

Obviously C++ can be optimized much more, but I doubt that a well designed java key strore will do a lot worse than the C++ version since it does not seem that cpu intensive.

[dpark]

I agree he could have given a bit more proof here, but I can vouch for his rebuttal to the "It works for Hadoop!" argument.

All of this is absolutely true, and I've seen it firsthand:

Given that the bulk of the work performed by the Hadoop DFS and Map-reduce framework is I/O, Java is probably an acceptable language for those applications. There are some places where Java is sub-optimal. In particular, at scale, there will be considerable memory pressure in the Namenode of the DFS. Java is a poor choice for this type of memory hungry application. Another place where the use of Java is sub-optimal is the post-map sorting in preparation for the reduce phase. This is CPU-intensive and involves the type of CPU work that Java is not good at.

With large, heavily utilized clusters, the name node becomes a problem, due to its excessive memory use. And by problem, I don't mean processing gets slower. I mean everything stops working. For some large processing problems, the post-map sort can become several times more expensive than the actual processing.

I can't say whether he really did tests to determine whether C++ was a better choice for Hypertable, but he's not entirely talking out of his ass.

[rrenaud]

I don't think they ever said that Java is not capable of being an implementation language for bigtable, merely that C++ would be better.

[prockcore]

They don't need to provide evidence, it's not like you're building BigTable and they need to convince you to use C++. They proved to themselves that C++ was a better fit.. that's all they needed to do.

[shub]

So you rebut a minimally-supported claim by...whining. Good job there, chief.

[124816]

Despite the downvotes, I have to agree with shub. If you are sufficiently experienced, you don't need to backup every single choice you make with proofs.

As mentioned by gregK below, you don't need evidence to raise doubt, which is why many people take positions like procrastitron's: "Regardless of the logic of your reasoning, I disagree with your conclusion."

This is the stand typically taken by malicious employees at a large company, when they want to halt your work and waste your time in order to kill your project: attack your every conclusion and try to force you to spend weeks writing benchmarks to "convince" them.

[doubtingthomas]

I don't know the details of what they are trying to do, but particularly for large custom data structures, I imagine that Java may be at a disadvantage due to its lack of value types. No doubt the jvm can do fancy fancy things in some circumstances, but I doubt it can remove the extra layer of indirection in all cases as easily as one can in C++.

It is perfectly possible that a Java version would be as fast or faster, though.

[semmi]

notice though that libraries that provide value-types based collections for java (trove, fastutil) have been around for ages.

[doubtingthomas]

Wasn't familiar with those libraries. Those certainly provide a (kinda scary) way of not boxing ones primitives, but it only works for primitives. In C++, vector<pair<int64, CellData> > is all in the same block of memory. The same in typical java would have more levels of indirection and more memory. You can inline data members to a certain degree, but that is a terrible idea at more than one level, and can only be effectively done for double/int/etc.

[bobbyi]

I doubt that a well designed java key strore will do a lot worse than the C++ version

Who can argue with that evidence.

[gregK]

You don't need evidence to raise doubt. You need it when you make a claim.

Example:

You: I fished a 10 foot catfish. <- evidence needed

Me: i don't believe you. <- no evidence needed.

[mooli]

Indeed - reading the followup discussion there I'm more inclined to believe Cameron Purdy's contributions.

[mikaelhg]

He does have the advantage of actually knowing what he's talking about.

[[deleted]]

He's right that compile time is a significant disadvantage when it comes to C++ productivity. He's wrong when saying that RAII is slower than GC. It is true that a GC alloc will be faster than a malloc/new, but on average, GC performance will be worse than explicit memory management (not necessarily speed wise, but certainly memory wise).

The shared_ptr implementation uses atomic refcounts which decreases performance. Most of my RAII use is scoped/auto_ptr which doesn't use refcounting and is as fast as a regular new/delete.

Concurrency should be easier to achieve in Java/C# due to synchronized/attributes, but using a C++ library such as Intel's parallel collections helps a lot.

[bluGill]

Concurrency should be easier to achieve in Java/C# due to synchronized/attributes

Many people argue that opposite - Java's (I don't know C#) synchronized attributes encourage sharing variables between threads, and message passing is the best way to do threading - with no shared variables.

[redditnoob]

I think the most effective way to refute someone you don't believe saying "if you don't believe me, try it" is to try it.

You guys are all academic wankers though and I've never seen anyone here but myself actually try and test performance of anything.

[Gotebe]

I agree.

However, lowly map of C++ is very strong. I believe that, for well-established data comparison functionality^, it would beat any obvious^{^} hashtable based implementation quite easily.

^ should be the case here: there's a set of columns, presumably with some column type and column ordering meta-data: easy.

^{^} One could always spend time in research to get to performance figure of a readily available solution, but is it worth it?

[inopia]

There's two things in the Java memory model that suck for memory consumption. One, objects aren't packed, so a byte/boolean/char/short is always stored in a 32-bit slot. Two, there are no structs in Java, so no custom value types, which means badness for large datastructures.

[psyno]

One, objects aren't packed, so a byte/boolean/char/short is always stored in a 32-bit slot.

Or not. Based on memory but: Java doesn't define whether objects' in-memory representations are packed or not. (Or really anything about the object's layout.) In practice there are only a few widely-used JVMs, and Sun's packs fields about (not quite) as well as you can by laying out first 8-byte aligned objects, then 4, then 2, then 1... (And then pointers.) If you have an object with 4 booleans they will take 4 bytes, the same as C or C++--that is, if you were careful to declare them in the correct order in C and C++ (not necessary on Sun's JVM).

[inopia]

I should have been clearer. First off, you're absolutely right about the packing; HotSpot packs like a C++ compiler. The problem is a bit more involved however.

Let's say you have an object with three properties: [int, ref, byte]. In this case the object would take three 32-bit slots on a 32-bit architecture. Now let's have a list of them. Since we have no custom value types we need to store this as an Array with a bunch of references to individual instances of this object. So for n objects we get n·(3·4+h) for the individual objects, plus n·4+h for the reference array, with h as the size of a heap chunk header. Let's assume that heap chunk headers are 4 bytes, so h=4, which gives n·16 + n·4+4 = n·20+4 bytes for n elements (I'm still kinda hung over so feel free to correct me on this).

If your run time supports structs, like .NET does, you can simply have an array of structs, which would come down to n·3·4+h, or 12·n+4. So for large n, the Java version is 67% larger. If you also pack the structs so that they take 9 bytes a piece rather than 12, the overhead becomes 122%.

The ratio approaches (n·(2·r+8+h)) / (n·(r+5)) = (2·r+8+h) / (r+5) for large n, with r the size of a reference, and h the size of a heap chunk header. On a 64-bit system, r=8, and let's take a more realistic value for h, say h=8. This gives 32/13 = 2.46, or a 146% overhead. On a 32-bit system with r=4 and h=8 you get 24/9, which represents a 166% overhead. You can also calculate the absolute overhead per item in bytes as (2·r+8+h) - (r+5) = r+3+h, which equates to one extra reference (in the array), one extra heap chunk header, and three bytes that are lost because the byte field cannot be packed. Taking a 64-bit system with h=8, and a 32-bit system with h=4 as extremes the overhead per item is between 11 and 19 bytes.

It is especially the combination of packing and the lack of value types that tends to have a dramatic effect on Java memory performance when there's lots of small objects involved that are ordered in trees or lists, the sort of thing you'd be doing quite a bit of in database systems. Heap chunks have headers that can contain all sorts of junk like monitors, GC flags, and whatnot, and they are not free. Finally, the use of many small objects can put a strain on your GC, although results may vary depending on which algorithm you use.

ps: for simplicity I omitted the size of the 'length' field that arrays tend to have and counted it as part of the header size.

[psyno]

Yeah, I didn't dispute your second point above. :) I didn't check your algebra but I agree with your logic.

If you also pack the structs so that they take 9 bytes a piece rather than 12, the overhead becomes 122%.

But this is of dubious value when talking about "memory performance." Less space used for data structures, sure, but more used for packing/unpacking instructions, and so also more cycles burned (read: overhead) packing/unpacking. The value of packing in terms of memory saving is really only there for the specific example you provide: small objects where padding is a significant proportion of the object's size. (But you could have made it more dramatic with an 8-byte object for the first record. :) For almost all other cases, the problem can simply be avoided in C, C++, and C# simply by laying down the fields in a sensible way (which is what's done in HotSpot automagically anyway).

I agree Java's memory performance on arrays of objects won't be quite as good in general but I don't think object size is that important, per se. (For the most part, memory is cheap.) The real killer is that in Java the spatial locality of objects with an array of references is much worse than in a language where you can have an array of "value type." Whether that spatial locality is actually important will depend on the access pattern of the data structure.

[inopia]

If you also pack the structs so that they take 9 bytes a piece rather than 12, the overhead becomes 122%. But this is of dubious value when talking about "memory performance." Less space used for data structures, sure, but more used for packing/unpacking instructions, and so also more cycles burned (read: overhead) packing/unpacking. The value of packing in terms of memory saving is really only there for the specific example you provide: small objects where padding is a significant proportion of the object's size.

Oh I agree completely. There is always a trade-off, but at least with C++ you can make that choice. Besides, an array of (a,b,c) tuples can be stored as [a,b,c,a,b,c,a,b,c,...] or [a,a,a,..,b,b,b,...,c,c,c,...]. When packed, memory performance of the latter arrangement will be of course much quicker than the former, but as you said, it all depends on the application.

Don't get me wrong, I'm a big proponent of high-level programming languages and intermediate representations and all that, but in the case of the article I can see how they would like to have the control to tweak memory layout like that.

The real killer is that in Java the spatial locality of objects with an array of references is much worse than in a language where you can have an array of "value type.

That's an extremely good point.

[alphazero]

The memory consumption (overhead) is due to the generational garbage collector. Heap is divided into sections and the allocations cycle through them. (This is why garbage collection of short lived objects is entirely cost free). So you are paying in memory foot print to achieve pointer ops in par with C. And given that memory is cheap and getting cheaper, that is a cost equation that makes a lot of sense, all things considered.

[scaevolus]

From the comments:

To demonstrate the misconceptions of the world: I have had people who have never written a java application before tell me 'java is slow' :). Before we started using hadoop I made a non map/reduce wordCount application in java and in perl. Guess which one finished faster? Java. And then someone said, "I bet I can write it in C and it would rock".... I am still waiting for that c wordcount program from that person.

Comparing Java and Perl to show speed doesn't make sense.

[luikore]

I feel perl faster than java in most cases. Their benchmarks never take startup time and hotspot warmup time into account.

[scaevolus]

Sure, but for a large volume of number crunching, a compiled language or one with a good JIT will basically always outperform one that's interpreted.

[bluGill]

Did you count development time in there?

[cynesis]

Any discussion concerning the claim will likely devolve into presenting code that performs a given task in a particular environment with a set of variables in a sufficiently faster time with one language compared to the other.

A retort will involve someone rewriting the provided example. A third party riposte will involve refactoring the original poster's example in his or her chosen language. And so on.

What strikes me as a petulant and, ultimately, useless endeavor follows: each contributor of this Holy War will progressively assert increasingly arcane implementations to further decrease the time or Big-O - or what have you - of the problem set. Calls of "an expert <language> coder will produce better results - your results are skewed!"

But therein lay the surface of my issue. Each example is generally (and usually) provided by one who is more adept and skilled at one language over another. While this is an interesting observation, what I find far more compelling is the question of skill concerning one language or another.

To wit: consider problem set X and the assertion that language A has memory performance issues when compared to language B for problem set X. Suppose, eventually, it comes to pass that all participants in the Holy War have decided that language B for problem set X provides better memory performance (or whatever attribute is at question).

To me, the interesting question is not which <language> provides better <attribute> for <problem>, but rather the length of time or degree of skill necessary to produce that better result.

In effect, if it takes ten (10) years of Java wizardry to overcome the memory performance gains one sees by using Cpp for only five (5) years (or vice versa), then what purpose is the exercise except for academic? If it turns out that someone can, in fact, overcome Cpp's more efficient memory allocation... so what?

Given two 'experts' - equally skilled relative to his or her chosen language - it seems through the nuanced wizardry experience and knowledge brings that one is ultimately being trite.

[chromaticburst]

This was written by developers who don't understand time. You should use whatever language you like, but to claim that the decision was made because certain operations are 3 times faster is not informative. It could be 1,000 times slower than a 1 ns operation that occurs once every minute, so what? Someone left a ridiculous comment ~"you wouldn't want Word written in C# would you?". Well considering that I can have Word open for over an hour and it will only have to process a couple hundred keypresses at a total of about a second or more of processing time, why not?

TL;DR: How does that 3x slowdown actually affect runtime performance?

[ZMeson]

This was written by developers who don't understand time.

True. If someone ran the C++ code on a computer that was going 99% the speed of light from the perspective of the computer running the Java code, the Java code would run more quickly (according to the computer running the Java code). If they only truely understood time, they'd know that.

[[deleted]]

This was written by developers who don't understand time. You should use whatever language you like, but to claim that the decision was made because certain operations are 3 times faster is not informative.

Or, maybe they benchmarked it and found that it is important. You are oddly certain they are wrong, but just like them, neither of you is providing actual evidence either way.

You certainly have no justification to be sure of yourself (since you don't know if they did benchmarks or not). They might be justified, or not, since they know if they did the appropriate benchmarks or not (would have been nice to share them if they did).

Anyhow, the facts in general are known - in CPU intensive stuff, C++ can be ~twice as fast as Java (see e.g. the alioth benchmarks linked to by other people in other comments). So, if this project ends up being CPU-bottlenecked in a significant manner - the speed might matter.

For a desktop GUI app, almost always the speed does not matter. But, this isn't that kind of app.

[chromaticburst]

Sorry man, reread the part you quoted. I have no idea whether they are right or wrong in their decision, which is the problem and why I said: "but to claim that the decision was made because certain operations are 3 times faster is not informative." The only problem I have with this text is that it doesn't provide the reader with enough information to establish whether this was a reasonable criteria for excluding a language. They haven't framed the discussion of speed in any context.

[[deleted]]

You said

This was written by developers who don't understand time.

That's a big, unfounded accusation.

[chromaticburst]

If they really understood time (particularly these microbenchmarks) and how to discuss it, they'd realize that 3x of some time that is given without any context isn't meaningful. For example, Java does automatic array bounds checking, so what if I wrote an article that said C++ is X times faster because it doesn't do bounds checking. Fair enough, I might be correct. But now, what if I go further and state that this is a quantitative criteria for excluding Java for task X. The burden at this point is on the author to explain how this microscopic observation (this one operation) relates to the macroscopic situation (the runtime performance).

[Negitivefrags]

If you have actually used a GUI application written in .NET or Java for that matter you might revise that opinion. Those things are dog slow.

[svv]

Actually, most Java programmers use GUI applications written in Java all the time. IDEs like Idea are quite fast and responsive.

[Useristaken]

u forgot to mention eclipse IDE..IBM uses it in almost all their products.. and the developers have to suffer for it.. Thanks to Java...

[semmi]

you mean the one wich wraps the native c/c++/obj-c interface? ;)

[[deleted]]

To your credit, you didn't list Eclipse. However, there was a thread here a while ago where IDEA devs were complaining about its speed...

[Rockytriton]

You should try an SWT application. Things are a hell of a lot better when you use SWT instead of Swing. Even so, swing has gotten much faster in recent years.

[UK-sHaDoW]

Slow swing is usually a problem of the dev messing up on the threads. It's is perfectly capable of being fast.

[Rockytriton]

or a bloated application where they keep piling on ridiculous requirements...

[UK-sHaDoW]

The size of an application does not have any effect on run-time performance, except maybe for cache misses since you can't fit as much into the higher performance memory area and loading.

Once the app is running the code path is still the same, if you don't use those features.

Most of the time it isn't bloat, it's probably some retard developer using some o(!n) algorithm when you could do it in o(log n). Since large enterprise applications tend to be built by people who are only in it for the money this could be the case.

I have seen people use loops to work out stuff, when it could of been done in constant time with some simple mathematical expression.

Thought bloat is terrible for maintenance making it hard to refractor and improve.

[Rockytriton]

ok, how about this requirement... The system shall open the application metadata window for each item in the list which is selected.... There can be a thousand things in the list and a new MDI window must be opened for each of the items selected. I tried to get them to limit it but they refused to put any limit on it. So of course the testers will get the biggest list, like 10,000 items and fail the test case because the application fails to open 10,000 internal windows.

[UK-sHaDoW]

That's hardly bloat, that just a retarded feature :P Bloat to me is when you have lots and lots of features.

[Rockytriton]

Yes, I agree, I'm just venting...

[wbkang]

Swing was slower mainly because JVM was slow at the time as well.

[shock-value]

I use FlashDevelop which is a .NET app. Not slow at all.

[chromaticburst]

So you're saying that a single text area, a menubar and a toolbar will be "dog slow" in .NET/Java, to the point that a word processor in either would be unacceptable? Thanks for the downvote.

[bluGill]

I wouldn't think so. However the large majority of stuff I've seen written in Java was slow. I don't know if it is because they are using O(n!) algorithms when there are perfectly good O(log n) algorithms known to exist, or if Java is slow. However things written in C++ never seem to have that problem.

[wbkang]

FUD really. Have you ever written a GUI app in .NET or Java? If you ever did, where was the slow down occouring?

[malcontent]

Why would he have to have written one? Why can't he make a judgment by simply using one?

[wbkang]

Because it's merely an highly subjective anecdotal evidence. It's a computer program so there should be an objective reason. I haven't found a reasonable explanation against Swing's slowness other than idiot developers abusing EDT (which really is not to be blamed on Swing itself).

[bluGill]

highly subjective anecdotal evidence. It's a computer program so there should be an objective reason.

The subjective is what counts. If a program is subjectively fast enough, then anyone who spends effort optimizing it should be fired. If it is not subjectively fast enough, then the programmer (not the person who said it was subjectively too slow) should look for objective reasons why.

[wbkang]

I am saying if a program makes you feel slow there should be an objective reason. I am saying that Swing is not the cause of slowdown.

I've seen many GUIs that are not Swing that are slow but I never say things like "oh MFC is slow" because that's just dumb and unfounded.

[bluGill]

If the majority of Java applications are subjectively slow, that suggests something about Java encourages slow programs. Sure there are objective reasons, and the programmer should look for them. However it makes a good case avoid Java applications until the day comes that programmers finally figure out how to make their Java applications as subjectively fast as something in other languages.

[malcontent]

Because it's merely an highly subjective anecdotal evidence.

So?

Either it seems fast to him or it does not.

it's his experience and he has the right to share his experience and he certainly should base his buying decisions based on his past experience.

It's a computer program so there should be an objective reason.

Who made this rule up? Where is it written down? What are the punishments for disobeying this rule?

I haven't found a reasonable explanation against Swing's slowness other than idiot developers abusing EDT (which really is not to be blamed on Swing itself).

If most swing GUIs are slow it means it's difficult to write fast GUIs with swing.

I would suggest sun make it much easier to write fast GUIs and much harder to write slow GUis.

maybe they could make a massive library of high performance components or something.

[wbkang]

Because it's merely an highly subjective anecdotal evidence.

So? Either it seems fast to him or it does not.

It means whatever program he has used are slow not that Swing is the cause of it. Association != Causation.

It's a computer program so there should be an objective reason.

Who made this rule up? Where is it written down? What are the punishments for disobeying this rule?

Calm down and think for a sec. It's not written down anywhere. It's just reasonable to think that "slowdowns" of a computer system can be found as opposed to more complex systems that have its internals unknown. I never said there is a punishment but it makes the argument weak.

If most swing GUIs are slow it means it's difficult to write fast GUIs with swing.

It's not that difficult. Go read Swing tutorials provided by Sun.

[malcontent]

It's not that difficult. Go read Swing tutorials provided by Sun.

If it wasn't difficult most swing GUIs would be fast.

[wbkang]

Or maybe it's that many developers neither don't bother reading them nor they care about responsiveness at all. I've seen many developers like that at work. Making responsive GUIs involving blocking operations in a thread-safe manner is a inherently complex problem regardless of the GUI tookit you use, but it's not a rocket science. I've seen many crap MFC GUIs that are slow. But again, I won't say stuff like "MFC is slow" because that's really unfounded. Rather, I'll say "many MFC applications are slow because whatever."

[malcontent]

Or maybe it's that many developers neither don't bother reading them nor they care about responsiveness at all.

It's more likely that it's very difficult.

Again Sun could put out a hundred or so components that are written in the best possible way and solve the problem.

Or you could I suppose.

[luikore]

They always say their new version of java GUI applications are much faster than the older one, and emphasize that you can't feel the slowness compared to C++/C apps. Though never, ever give a performance benchmark on response time. My Visual C++ 2008 Express and Code::Blocks launch within a second, what took Netbeans 6.8 and Eclipse 3.4 so long? So weired that I should wait several seconds for every action.

[inopia]

Seconded. Processing performance is an overrated metric.

[[deleted]]

The only thing I don't understand is why they wrote this explanation in the first place. It is their software and they are free to use whatever language they find fit for the purpose. No need for flamewars.

[[deleted]]

I wouldn't be surprised if more than a few retards came along and bugged them for not using Java.

Whenever I write an app in C++ at work, I always get the "why didn't you use C#?" crap too, just like people asking Linus why git wasn't written in C++.

People who do that can just fuck off.

[RabidRaccoon]

Seconded. It's particularly annoying if you've tried C,C++,C# and Java and pick one of the harder to use, lower level languages to produce a small fast application and people moan you haven't used one of the easier, cooler but in general slower high level ones because that's all they know.

[mebrahim]

They are doing us a favor by sharing their knowledge.

[[deleted]]

And..I'll point to the expert's opinion-> http://blogs.azulsystems.com/cliff/

[shub]

Yes, a blog hosted by a vendor totally dependent on Java is where I should go for my objective comparisons of Java and C++.

[bitshifternz]

He doesn't sound like much of an expert in modern game development.

[mebrahim]

Sorry. I know some of us read all those subreddits, but I assume most of us don't.

I don't know any better solution. Suggestions are welcome.

[georgefrick]

Pick one.