Comment On Java is Slow!

Pete and his manager Dick were ACME Corporation's version of The Odd Couple. They both shared in the support and maintenance of a monstrous in-house spawned order processing / network monitoring / invoice printing / slashy / slash / slash system written in Visual C++. However, while Pete kept up in the latest technology trends and was always on the lookout for new solutions to old problems, Dick was a very conservative manager with twenty-five company years under his belt. To Dick, "change" was only a Good Thing when it added up to 65¢, which was the exact amount required to buy a ginger ale from the soda machine. What kept Pete and Dick from being a perfect couple was that Dick was Pete's supervisor and often times, he got his way. [expand full text]
« PrevPage 1 | Page 2 | Page 3 | Page 4 | Page 5 | Page 6Next »

Re: Java is Slow!

2009-05-12 16:28 • by xtremezone
261275 in reply to 261263
BikeHelmet:
C++ is roughly that much slower than assembly, but you'd take C++ over ASM because of the dev time alone.

And don't give me that crap about the modern compiler optimizing more than assembly can. If you write the entire program in ASM, it will be significantly faster than a C++ program would be.
A compiler will make better optimizations than 99% of us can. So a program written in C or C++ will probably be near equal to or probably even faster than the equivalent program written by the same programmers in assembly.

Java? C++? C#? You are insane!

2009-05-12 16:34 • by Daniel (unregistered)
Why do you keep discussing these outdated languages? Learn Scala and get on with the program.

Re: Java is Slow!

2009-05-12 16:35 • by xtremezone
261277 in reply to 261265
Franz Kafka:
If you can't figure our marketing driven naming, then you may not be cut out for marketing.
FTFY.

Re: Java is Slow!

2009-05-12 16:36 • by GrandmasterB (unregistered)
Choosing C++ over Java is not a WTF. If anything, its the anti-WTF.

Re: Java is Slow!

2009-05-12 16:37 • by Michael J (unregistered)
261279 in reply to 261186
Java has steadily increased in speed to the point it is in the same order of magnitude as C code. The advantage of a static compilation vs. dynamic compilation is immense. We are replacing C code with EJB3 code at present, and the performance increase is approximately 41x. The difference is in how easy it is to distribute the work. If we need to increase performance we let the app server create another MDB. If the server runs out of capacity, we add another. The point is that C and to a degree C++ suck arse in performance in most applications. Java and .Net as Virtual Machine based languages are the future. Long live the VM.

Re: Java is Slow!

2009-05-12 16:39 • by WWWWolf
261281 in reply to 261247
SomeCoder:
I've seen the Quake 2 port from C to C++.NET (CLR). It was quite a bit slower but in practice it was at least playable. The framerate suffered more than I would have liked for a video game though


There's also a port of Quake 2 for Java. Can't remember where it was, but it was pretty scary-awesome - click a link, JWS pops up, you tell it where your Quake2 data lives, boom, you get a pretty decently working Q2.

Re: Java is Slow!

2009-05-12 16:45 • by Buddy (unregistered)
261282 in reply to 261214
SomeCoder:
BoomWav:
In a enterprise environment, maintainability is WAY WAY more important than performance most of the time.


Which is why computers get faster and yet when you get a new machine, they run as slow or slower as your old machine. The new software eats up all of the new hardware's capability...


You really see it when you run old stuff on new machines - everything runs and finishes, meanwhile your finger hasn't left the enter key.

Re: Java is Slow!

2009-05-12 16:45 • by iMalc (unregistered)
261283 in reply to 261234
C4I_Officer:
Anon:
The reality is that Java remains to this day far slower than an application that gets compiled to native code. Whether or not that matters depends on the specific case - generally the additional memory usage and startup time don't matter in long-running environments where memory is plentiful.



The Java is Faster than C++ and C++ Sucks Unbiased Benchmark.

Have fun ;-)
Not so fast...

'The Java Faster than C++' Benchmark Revisited

Happy trolling ;-)

Re: Java is Slow!

2009-05-12 16:52 • by Fedaykin (unregistered)
[quote user="xtremezone"]A library is just reused code and that concept still exists for Java on top of the JVM. Java programs need to be run inside of the JVM, which is a different concept all together, and qualifies as "special software" IMHO.[/quote]

Different purpose? Sure. Fundamentally different? No.

[quote]
In college (two years ago), one of the things that confused the Hell out of me was how I could be downloading version 5 of the JDK or JRE if the most recent version was 1.5... WTF?! I didn't figure out WTF they were doing until a year outside of college...
[/quote]

So that Java 5 == JVM version 1.5 is a highly confusing concept for you?

[quote]Sure, show the C-like syntax to try to make it seem the same, but any C/C++ coder that's moved on to Java will quickly point out the frustrating semantics. For example, immutable strings.[/code]

You are confusing core language semantics with the semantics of a particular library or class.

To get on a sidetrack, the String class in Java is immutable for a very good reason: multi-threading and performance (something Java and its core libraries were designed for from the ground up). If you need mutable but still thread safe strings use a StringBuffer. If you don't care about thread safety you can also use a StringBuilder which is generally the fastest mutable String manipulation class in the core libraries.

As a StringBuilder

StringBuilder name = new StringBuilder("john");
name.setCharAt(0, Character.toUpperCase(name.charAt(0));


[quote]Again, you're using C-like syntax to make it appear the same, when in reality there are very different semantics in Java. One of the things I find extremely ugly about Java code is that there are no operator overloads (except for those provided as part of the language, like operator+ for String) which results in lots of verbose, nested method calls with really long lines (or that many more lines if you split it up).[/quote]

This is one reason why Java 1.5 and above have Autoboxing which allows you to treat Objects and primitives interchangeably (with an equalities caveat).

Now, while operator overloading can be useful, the functionality is just as easily done with other language tools (methods, classes, etc.) and arguably much more clearly.

There isn't a great deal of gain to be had from something like:

cout << MyObject;

over the much more clear:

MyObject.print();

There's nothing you can do with operator overloading that you can't do in a different and often more clear way. The latter is also a more elegant solution because it allows for proper encapsulation of functionality.

Plus, you won't have some jackass who overloads the dot operator or some stupid thing like that.

[quote]I'm not trying to come across as a senseless Java basher. I recognize that Java has its niche and can be used effectively. I just haven't really found it useful yet, and I've tried many times (both in college and out).[/quote]

I agree that Java is not a very good solution for desktop apps, but desktop apps are only a small portion of apps. Java excels in the enterprise environment.

[quote]
The syntax of Java is very similar to C and C++ because it's a C-like language. The semantics, however, are VERY different. If you don't understand semantics, implicitly passing arguments by reference is an example of a semantic with consequences.
[/quote]

Are you claiming that C++ does not have pass by reference?

[quote]
Another thing that bothers me about Java is its lack of constants...
[/quote]

WTF? Have you ever actually programmed in Java? It doesn't allow GLOBAL constants (though you can easily achieve the same functionality), but to say that Java doesn't have constants is nonsensical.

Re: Java is Slow!

2009-05-12 16:55 • by xtremezone
261286 in reply to 261268
Zer0:
C-strings. Blah. I think char arrays have been beaten to death, so I think that's why string classes showed up to begin with. Sounds like a step backwards. Not sure how in the world that's brilliant...
It's brilliant because it makes sense. Strings are and always have been arrays of characters. In the days of C and C++, arrays were just dumb sequential bytes of memory though. You needed external routines to operate on them and it took time for the string libraries of today to develop.

Now that arrays are always objects in modern languages, it doesn't make sense to have a separate class for strings (StringBuilder, sure, but not string).

Anyway, I guess I take it back because it looks like D does has immutable strings (now, anyway). >_> However, you can still use an array of chars and accomplish everything if you need a mutable one. I liked the concept of "strings aren't special", which really they aren't... They're just arrays of data like any other data. We want to concatenate, replace, remove, join, splice, split, etc., all types of data in arrays.

What made it particularly nice (and I forget most of it now) was the syntactic sugar for working with arrays. You didn't need to call methods on them a lot of the times because there were operators for lots of things. It's been so long I don't really remember anymore though.

Re: Java is Slow!

2009-05-12 16:58 • by jro (unregistered)
261287 in reply to 261155
zoips:
Wait, let me guess, Dick was given a raise for that, right?


Sicko:

Re: Java is Slow!

2009-05-12 17:02 • by xtremezone
261288 in reply to 261285
Fedaykin:
Are you claiming that C++ does not have pass by reference?
Of course not. Don't be ridiculous. Your reading comprehension is broken. I said IMPLICITLY passing arguments by reference. In C++, you have to explicitly declare reference parameters or the data will be copied. Which I prefer because it allows a way to keep data from being changed unintentionally.

In C#, I haven't found a solution for this problem... You pass an object into a method and to my knowledge you have no way to ensure that the method doesn't modify it... AFAIK, Java is the same.
Fedaykin:
WTF? Have you ever actually programmed in Java? It doesn't allow GLOBAL constants (though you can easily achieve the same functionality), but to say that Java doesn't have constants is nonsensical.
Of course I have, but only a little bit here and there. I play with it now and then until I get frustrated with the semantics and return to the sane world of me being in control. :D

Please demonstrate how to accomplish constants in Java. It's been a while, but as I remember it, final isn't the same thing...

Re: Java is Slow!

2009-05-12 17:16 • by Franz Kafka (unregistered)
261293 in reply to 261277
xtremezone:
Franz Kafka:
If you can't figure our marketing driven naming, then you may not be cut out for marketing.
FTFY.


If you can't outthink a marketer, then I'm very sorry.

xtremezone:
Zer0:
C-strings. Blah. I think char arrays have been beaten to death, so I think that's why string classes showed up to begin with. Sounds like a step backwards. Not sure how in the world that's brilliant...
It's brilliant because it makes sense. Strings are and always have been arrays of characters. In the days of C and C++, arrays were just dumb sequential bytes of memory though. You needed external routines to operate on them and it took time for the string libraries of today to develop.

Now that arrays are always objects in modern languages, it doesn't make sense to have a separate class for strings (StringBuilder, sure, but not string).


No, strings are not just arrays of chars, they are strings that happen to be stored as an array. Java Strings are an improvement over the mishmash of C++ string classes and I like them a lot better. If you don't like the slightly better abstraction, that's fine, but it isn't Java's problem.


xtremezone:

Please demonstrate how to accomplish constants in Java. It's been a while, but as I remember it, final isn't the same thing...


public static final String CONSTANT="Some stuff"

xtremezone:
Fedaykin:
Are you claiming that C++ does not have pass by reference?
Of course not. Don't be ridiculous. Your reading comprehension is broken. I said IMPLICITLY passing arguments by reference. In C++, you have to explicitly declare reference parameters or the data will be copied. Which I prefer because it allows a way to keep data from being changed unintentionally.


The only reliable way is to use immutable objects, like your maligned String.

Re: Java is Slow!

2009-05-12 17:20 • by anonymous wanker. (unregistered)
261294 in reply to 261224
I was at a conference and they were describing the NUnit framework. (or was it XUnit?)

NUnit 0.1 was simply JUnit run through the C# compiler. They then fixed all the errors, lather rinse repeat until it compiled.

They said it was the fastest way to get a port running.

Re: Java is Slow!

2009-05-12 17:25 • by Zer0 (unregistered)
261297 in reply to 261293
[quote user="Franz Kafka"][quote user="xtremezone]
Blah blah blah
[/quote][quote]

Um, hate to break it to you, but there's NO way in C++ to ensure a method doesn't modify a variable so I'm not sure why in the world you're expecting that from C# (and there are design patterns to account for this - cough properties cough). If you're starting to think 'const' ensures constness in C++, please read-up about it and don't bother replying. Also, C++ doesn't have constants. C# does.

Some code-

C++

const - not guaranteed to be constant

C#

const - guaranteed to be constant


C# wins.


Java

public static final String FAKE_CONSTANT = "Some stuff"

C#

public static readonly string FAKE_CONSTANT = "Some stuff";


Tie.


C#

public const string REAL_CONSTANT = "Some stuff";

Java

none


C# wins. =P


Re: Java is Slow!

2009-05-12 17:26 • by Charles400
If your company has a Dick, keep him zipped.

Re: Java is Slow!

2009-05-12 17:32 • by Franz Kafka (unregistered)
Do tell: how do Java constants differ from C# constants? Specifically, why is the Java constant 'fake'?

Re: Java is Slow!

2009-05-12 17:37 • by Jim S. (unregistered)
261301 in reply to 261281
That would be jake.


And for the comments about pass by reference vs. pass by value:

Java passes *everything* by value. End of story.

Explanation in mind-numbing detail can be found here

Re: Java is Slow!

2009-05-12 17:39 • by bENDER (unregistered)
261303 in reply to 261164
snoofle:
Zapp Brannigan:
My mom and dad had their budget in an Excel spreadsheet and they were constantly asking me for help. I re-wrote spreadsheet as a Java application and now they never ask for my help. Java Rules!


As a staunch Java advocate, to be fair, that just means you're a good app designer, not that Java rules.


If you rewrote my spreadsheets into a Java App, I'd never ask for your help either.

(My sarcasm detector may have malfunctioned when I read this...)

Re: Java is Slow!

2009-05-12 17:42 • by gr (unregistered)
Knock knock.

Who's there?

Java.

Java who?

Java na lemme in, already?

Re: Java is Slow!

2009-05-12 17:42 • by Franz Kafka (unregistered)
261305 in reply to 261301
Jim S.:
That would be jake.


And for the comments about pass by reference vs. pass by value:

Java passes *everything* by value. End of story.

Explanation in mind-numbing detail can be found here


This is true, however the value is an object ref, so it behaves much like pass by ref.

Re: Java is Slow!

2009-05-12 17:43 • by Ref (unregistered)
261306 in reply to 261191
j_random_hacker:
Java slow? Nooo. That may have been true once, but everyone knows that nowadays Java code typically runs 500 times faster than assembly.

Sometimes a method will finish running before it began!


GOAL!!!!

Re: Java is Slow!

2009-05-12 17:52 • by Johnno (unregistered)
261309 in reply to 261212
snoofle:
wee:
TRWTF is nobody proofreads shit.

Sorry, I gotta ask.... what braille-literate person would want that job?

hahahahahahahahahahahahaha.......

FMD, what a refreshing break from the "Java Rocks" vs "Java is Shite" debate.

I'll be laughing all day on that one.....

Re: Java is Slow!

2009-05-12 17:55 • by Pedant (unregistered)
Went & looked up that java quake2 port previously mentioned, and interestingly it had benchmarks!

http://bytonic.de/html/benchmarks.html

Fullscreen (probably more reliant on CPU)

C - 315fps
Java 1.5 - 250fps

Re: Java is Slow!

2009-05-12 17:59 • by Some Other Coder (unregistered)
261311 in reply to 261214
SomeCoder:
BoomWav:
In a enterprise environment, maintainability is WAY WAY more important than performance most of the time.


Which is why computers get faster and yet when you get a new machine, they run as slow or slower as your old machine. The new software eats up all of the new hardware's capability.

While I would agree that you have to consider development time vs performance, I see developers these days choosing development time far too often when performance is still needed. Saying that "Well the user has a gig of RAM/Fast CPU/quick hard drive/etc. so I can be lazy" is becoming acceptable and that is truly TRWTF.

That said, I would never agree with Dick in this particular situation :)


You have noticed, though, that while the apps eat much of the resource improvement, they do a hell of a lot more than they did on your old machine, haven't you?

Sure the resources get eaten up, and some of this may be lazy choice in development language, but some of it is because they have more bu..(I mean "Features"). Often the language chosen makes it easier for such features to be quickly added, and the difference to resource usage only becomes apparent because the application is doing more nifty little things.
In addition, choice of language can minimise problems down the track - a program written purely in assembler would be more likely to have (unknown) bugs. Quick is not always best, and lots more, but I suddenly can't be bothered....

Re: Java is Slow!

2009-05-12 18:02 • by ell0bo (unregistered)
261313 in reply to 261186
Anon:
Fedaykin:
What "special servers" and "special software" do you think is required to run Java?


Well, the Java Runtime Environment and Java Virtual Machine come to mind as special software. C++ applications don't require either of those to run.

The reality is that Java remains to this day far slower than an application that gets compiled to native code. Whether or not that matters depends on the specific case - generally the additional memory usage and startup time don't matter in long-running environments where memory is plentiful.

But suggesting that Java is lighter weight or faster than a well-written native application is ludicrous at best.


This reminds me of a project from college. I had to design an AI to trade stocks. I wrote the beta in C++, but then so my team could more easily work with me I rewrote the code in Java. It wasn't running very fast, so and I realized I could speed it up if I ran multiple threads. Well, this would be true if Java didn't go from a slight memory hog to a devourer of all memory as soon as you start forking off processes. My prof told me no one ever managed to kill the server before, I was kinda proud (and I had the spawn limit set to only 4 threads. When we got the proof of concept working, I rewrote it in C++, and it brought a tear to my eye.

Re: Java is Slow!

2009-05-12 18:06 • by Fedaykin (unregistered)
261314 in reply to 261288
xtremezone:

In C#, I haven't found a solution for this problem... You pass an object into a method and to my knowledge you have no way to ensure that the method doesn't modify it... AFAIK, Java is the same.


Using proper encapsulation and access controls is the proper way to prevent unintended modification of your class members.

Is there some other issue you have?


Please demonstrate how to accomplish constants in Java. It's been a while, but as I remember it, final isn't the same thing...



public class Globals {

public static final int MY_GLOBAL_CONST = 1;

}


Re: Java is Slow!

2009-05-12 18:07 • by Blingot (unregistered)
261315 in reply to 261219
Franz Kafka:
Anon:
Fedaykin:
What "special servers" and "special software" do you think is required to run Java?


Well, the Java Runtime Environment and Java Virtual Machine come to mind as special software. C++ applications don't require either of those to run.

The reality is that Java remains to this day far slower than an application that gets compiled to native code. Whether or not that matters depends on the specific case - generally the additional memory usage and startup time don't matter in long-running environments where memory is plentiful.

But suggesting that Java is lighter weight or faster than a well-written native application is ludicrous at best.


C++ apps have a runtime too, but so what? The jdk is easily found and installed. The special server thing has been dropped, I see - good thing too, since java servers are just like other servers.

Java is absolutely fasater than C++ when you consider dev time.


Errm...I don't think a special runtime needs to be installed before a c++ app can be run (unlike the Java which [I think] needs the JRE installed)

How is Java dev time any quicker to c++ dev time? They are (on the whole) very similar languages (and have very similar libraries [although I'm not sure that's what java calls them - classes, perhaps] available to them).

Let me say I am not anti-Java, and think (as with most things) there is a time and place for it, however to try to make an argument that it is an easier or quicker language to use than c++ is laughable at best. That being said, to make the claim the opposite way is probably laughable too - in terms of development, I can't see that there would be significant savings in dev time using either of them - other than if you don't know one of them as well as the other, that one would probably take you longer to debug.

Re: Java is Slow!

2009-05-12 18:20 • by Franz Kafka (unregistered)
261316 in reply to 261315
Blingot:
Franz Kafka:
Anon:
Fedaykin:
What "special servers" and "special software" do you think is required to run Java?


Well, the Java Runtime Environment and Java Virtual Machine come to mind as special software. C++ applications don't require either of those to run.

The reality is that Java remains to this day far slower than an application that gets compiled to native code. Whether or not that matters depends on the specific case - generally the additional memory usage and startup time don't matter in long-running environments where memory is plentiful.

But suggesting that Java is lighter weight or faster than a well-written native application is ludicrous at best.


C++ apps have a runtime too, but so what? The jdk is easily found and installed. The special server thing has been dropped, I see - good thing too, since java servers are just like other servers.

Java is absolutely fasater than C++ when you consider dev time.


Errm...I don't think a special runtime needs to be installed before a c++ app can be run (unlike the Java which [I think] needs the JRE installed)

How is Java dev time any quicker to c++ dev time? They are (on the whole) very similar languages (and have very similar libraries [although I'm not sure that's what java calls them - classes, perhaps] available to them).

Let me say I am not anti-Java, and think (as with most things) there is a time and place for it, however to try to make an argument that it is an easier or quicker language to use than c++ is laughable at best. That being said, to make the claim the opposite way is probably laughable too - in terms of development, I can't see that there would be significant savings in dev time using either of them - other than if you don't know one of them as well as the other, that one would probably take you longer to debug.


Yes a runtime does need to be installed for C++. The only difference is that the runtime is almost always installed already

Java dev cycles are faster due to shorter compile loops and better behavior on failure - instead of a random memory stompage, you get an exception and a stack trace. In terms of web sites, java has a lot going for it over C++.

Re: Java is Slow!

2009-05-12 18:20 • by MZ (unregistered)
261317 in reply to 261227
BoomWav:

<snip>
It's important to take the right tool for the job. There's no language that is the best for all jobs. It's not like that and it never will.

At this time, from my POV, it's pretty clear.

If portability is important for you, I'd go with Java, everytime. It's the main strenght of Java, there's no doubt into that. Java is easy enough to maintain too. It a bit hard to find good people however since there's a broad range of different libraries that do the same things making experience difficult to acquire.

C++ is the expert language. It's good for really dedicated application. You have so much freedom into everything that it's the easiest way to make your tool the best for its job. You can have no tradeoff at all. Put everything in performance or memory management for the maximum boost. It's difficult to maintain however and the deadlines are always too close for everybody. Ask the game developpers.

C# with the .NET framework is really appealing to a lot of people. You can go web-based with the same code with ASP.NET. The .NET framework is really solid too and well known. If you hire someone with C# experience, you know he will do the job since .NET is universal. It's also faster than java and is better supported.

I might be biaised however but it's my view on things.


I don't understand how Java Code is more maintainable than c++?
Maintainability is largely affected by coding style, rather than by language. Finding people with enough experience to maintain either can be a difficult thing, but I don't see how maintaining one can be more difficult than the other - It boils down to the understanding of the language (and possibly the techniques used by predecessors). It may be easier to write obfuscated code in c++ than java, but this doesn't suggest that c++ developers write obfuscated code.

Deadlines are a management issue, and are not affected by the language. If you are suggesting that c++ takes longer to develop, I'm not convinced. A complicated App will always take longer to develop than a simple one, irrespective of language. If deadlines are tight, though, it's more to do with management and planning (I would think)

the .NET stuff confuses me a little. Is it somehow more universal than Java? If you hire someone with c# experience, he will do the job provided the job requires c# experience. If you hire someone with COBOL <**Shudder**> experience to fill a COBOL role, I'm sure they will do the job too. I'll take your word for c# being better supported ('cos frankly, I don't know any different).

As so many others have said it's a 'horses for courses' thing. All languages have different weaknesses, and most languages have some strengths, and are best suited to different tasks/applications. To say out and out that one language is better than another is a brave thing to do - particularly without much justification.

Re: Java is Slow!

2009-05-12 18:23 • by QuercusMax (unregistered)
261322 in reply to 261162
The funny thing is, there's actually a fairly big guy in the Java space named Rod Johnson (http://blog.springsource.com/author/rodj/) - he created the Spring suite of Java frameworks.

Definitely one of the manliest names ever, after Staff Sgt. Max Fightmaster.

Re: Java is Slow!

2009-05-12 18:23 • by Me (unregistered)
261325 in reply to 261229
BoomWav:
insquinormalc:
You think Java code is "ugly" and the "language semantics are a bitch", but would code in C#? Perhaps there's some other language called C# out there that I'm not aware of, but the one I use looks 95% the same as Java.


Yep, the code is really similar. Some syntax is better in C# however. The whole foreach() for example. Do not forget that the framework is also better in C#. Did you ever try to work with dates in Java? You'll want to kill yourself the first week you try to get something working. I exaggerate but so do you!


I don't use java much, but AFAIK foreach was introduced through the Iterator class around version 4 or 5...
As for Dates, I think the biggest problem in Java is that they made a mistake, and then tried to fix it causing confusion. Pretty sure one of the Calendar (or was that Date) classes would be equivalent to C# these days.

Re: Java is Slow!

2009-05-12 18:45 • by DOS (unregistered)
261330 in reply to 261260
EmperorOfCanada:
My experience with C++, .net and Java has generally been that C++ is often overkill for smaller applications. But with Java and .net you reach a certain point where you are fighting with the language itself to get to where you need to go. This results in a project where you spend the last half of the project in the "90% done" phase. With C+ you begin the fight with your first line of code but generally it will be able to plod along to a final product at a predictable speed.
I suspect that Dick not only didn't like Java but also didn't like anything new in C++ if I had to guess he also was still using MFC or something. Bring things like Boost and QT to the table and C++ can actually be fun to develop in.

All that said, I use PHP most of the time now. Right tool for the job is the real rule.

P.S. I use Eclipse for most coding and am regularly reminded that Java apps are almost always twitchy apps. Please find me a multi platform, multi language IDE developed in C++ please.



CodeBlocks (codeblocks.org) is supposedlymulti-platform, multi-language. I've only ever used it on win for c++ and c, so I don't know whether it supports other languages well (I know of people using it on various Unix Flavours).

Notepad++, though it isn't actually an IDE it has Syntax Highlighting, Code Folding and lots of other handy little tricks for a variety of languages

Xemacs - you either like emacs or you find it difficult


Re: Java is Slow!

2009-05-12 18:48 • by LordOfThePigs (unregistered)
261331 in reply to 261283
iMalc:
C4I_Officer:
Anon:
The reality is that Java remains to this day far slower than an application that gets compiled to native code. Whether or not that matters depends on the specific case - generally the additional memory usage and startup time don't matter in long-running environments where memory is plentiful.



The Java is Faster than C++ and C++ Sucks Unbiased Benchmark.

Have fun ;-)
Not so fast...

'The Java Faster than C++' Benchmark Revisited

Happy trolling ;-)


Both of these are over 4 years old... try that one for a more up-to-date and neutral roundup:

http://www.stefankrause.net/wp/?p=9

Re: Java is Slow!

2009-05-12 18:49 • by Gewn (unregistered)
261332 in reply to 261272
sylvic:
EmperorOfCanada:

P.S. I use Eclipse for most coding and am regularly reminded that Java apps are almost always twitchy apps. Please find me a multi platform, multi language IDE developed in C++ please.



emacs


I believe emacs is developed in LISP not C++

Re: Java is Slow!

2009-05-12 18:50 • by Omnifarious
My main issue with Java is that Hello World in Java is slower than it is in Python. This causes people to want to shove every single little thing every program on the system does into one VM because of the startup costs.

I think the world belongs to good 'scripting' languages like Python combined with C++ for optimizing the speed sensitive portions. I don't like Java at all. It has the worst tradeoff between ease of development, speed and verbosity of any language in popular use today.

Re: Java is Slow!

2009-05-12 18:52 • by Gewn (unregistered)
261334 in reply to 261283
iMalc:
C4I_Officer:
Anon:
The reality is that Java remains to this day far slower than an application that gets compiled to native code. Whether or not that matters depends on the specific case - generally the additional memory usage and startup time don't matter in long-running environments where memory is plentiful.



The Java is Faster than C++ and C++ Sucks Unbiased Benchmark.

Have fun ;-)
Not so fast...

'The Java Faster than C++' Benchmark Revisited

Happy trolling ;-)


I was thinking http://bruscy.republika.pl/pages/przemek/java_not_really_faster_than_cpp.html


There are many others....

Re: Java is Slow!

2009-05-12 19:03 • by LordOfThePigs (unregistered)
261336 in reply to 261283
And this one for a comparison of java with C#
http://kingrazi.blogspot.com/2008/05/shootout-c-net-vs-java-benchmarks.html

or even better:
The computer Language Benchmark Game for always up to date benchmarking of a lot of languages. Pretty cool benchmark place.

After that, the conclusion is Java is slower than C/C++, but not by an awful margin (around 50% slower)

Re: Java is Slow!

2009-05-12 19:08 • by Ralph (unregistered)
261338 in reply to 261297
[quote user="Zer0"][quote user="Franz Kafka"][quote user="xtremezone]
Blah blah blah
[/quote][quote]

Um, hate to break it to you, but there's NO way in C++ to ensure a method doesn't modify a variable so I'm not sure why in the world you're expecting that from C# (and there are design patterns to account for this - cough properties cough). If you're starting to think 'const' ensures constness in C++, please read-up about it and don't bother replying. Also, C++ doesn't have constants. C# does.

Some code-

C++

const - not guaranteed to be constant

C#

const - guaranteed to be constant


C# wins.


Java

public static final String FAKE_CONSTANT = "Some stuff"

C#

public static readonly string FAKE_CONSTANT = "Some stuff";


Tie.


C#

public const string REAL_CONSTANT = "Some stuff";

Java

none


C# wins. =P


[/quote]

perhaps I miss the point, but if you define a constant in c++ (ie use #define) is it not constant??
Forget const...

Re: Java is Slow!

2009-05-12 19:09 • by LordOfThePigs (unregistered)
261339 in reply to 261333
Omnifarious:
I don't like Java at all. It has the worst tradeoff between ease of development, speed and verbosity of any language in popular use today.

Well, according to the language shootout link posted above, java is more than 100 times faster than python 3, Ruby 1.9 and Perl, 50 times faster than PHP and Javascript with Tracemonkey.

The myth of Java beeing awfully slow is mainly due to the fact that is used to be, but isn't any more. It basically 3rd fastest, right after ASM and C/C++.

Re: Java is Slow!

2009-05-12 19:12 • by dkf
261341 in reply to 261248
xtremezone:
One of the things I find extremely ugly about Java code is that there are no operator overloads
If you claim operator overloading, then you also have to explain why shift operators make sense for I/O and how it is much easier to look at a bit of code and work out what it is really doing (where the costly activities are) with C++ given that virtually any symbol (and even some places without symbols) can be assigned near-arbitrary semantics.

Java makes you write out what you mean. This is certainly more bureaucratic, but it makes the life of maintenance programmers much better. That's really important for a lot of software...

Re: Java is Slow!

2009-05-12 19:14 • by LordOfThePigs (unregistered)
261342 in reply to 261338
Ralph:

perhaps I miss the point, but if you define a constant in c++ (ie use #define) is it not constant??
Forget const...

Not really, #define is preprocessor magic. This means that the preprocessor will basically copy whatever text is #defined everywhere it is referred to in the source code, before passing that modified code to the compiler. That works really well for int and other numeric types, but I'm unsure of how it really behaves with object or more complicated structures (my C++ is a bit too rusty).

IIRC, #define doesn't allow you to build a complicated object/structure and use the same copy multiple times accross your program. Due to the fact that it is just a preprocessor trick, you end up with many copies of the same data.

Re: Java is Slow!

2009-05-12 19:19 • by dkf
261344 in reply to 261227
BoomWav:
[C# is] also faster than java and is better supported.
Only on a single expensive platform with some distinct scaling issues. (To be frank, Mono doesn't count!) If you don't mind being non-portable and bound to the whole Windows platform for execution environments, C# isn't a bad choice. But that doesn't work for everything.

Re: Java is Slow!

2009-05-12 19:19 • by Tama (unregistered)
261345 in reply to 261288
xtremezone:
Fedaykin:
Are you claiming that C++ does not have pass by reference?
Of course not. Don't be ridiculous. Your reading comprehension is broken. I said IMPLICITLY passing arguments by reference. In C++, you have to explicitly declare reference parameters or the data will be copied. Which I prefer because it allows a way to keep data from being changed unintentionally.

In C#, I haven't found a solution for this problem... You pass an object into a method and to my knowledge you have no way to ensure that the method doesn't modify it... AFAIK, Java is the same.


Nope, there are several ways to deal with this: make your object immutable, wrap it in an immutable wrapper class, or make a defensive copy that you pass around (but that might end up being quite expensive since you need to make a copy of all the readable references your object holds if they don't refer to immutable object themselves).

First solution: if your class is immutable (like String, or the class Foo below), you can pass it around and it can never be modified:

public class Foo {
private final int _a;

public Foo(int a) {
_a = a;
}

public int getA() {
return _a;
}
}


Second solution: if you wrap your class in an immutable wrapper (like Collections.unmodifiableCollection() for instance - but beware references to other objects), it won't be able to be modified either:

public class Foo {
private int _a; // _a is a native type, so it's passed by value
private String _b; // _b is immutable, so cannot be modified by getB().setSomething()
private MyOtherClass _c; // We'll have to be careful about _c

public Foo(int a, String b, MyOtherClass c) {
_a = a;
_b = b;
_c = c;
}

public int getA() {
return _a;
}
public String getB() {
return _b;
}
public MyOtherClass getC() {
return _c;
}
public void setA(int a) {
_a = a;
}
public void setB(String b) {
_b = b;
}
public void setC(MyOtherClass c) {
_c = c;
}
}

public class FooWrapper extends Foo {
public MyOtherClass getC() {
// Wraps _c itself in an immutable wrapper
return new MyOtherClassWrapper(getC());
}
public void setA(int a) {
throw new UnsupportedOperationException();
}
public void setB(String b) {
throw new UnsupportedOperationException();
}
public void setC(MyOtherClass c) {
throw new UnsupportedOperationException();
}
}


Last solution: make a copy constructor, or introduce a copy() method (do NOT use clone() for that purpose). Implementation left as an exercise for the reader.

Re: Java is Slow!

2009-05-12 19:21 • by Betty (unregistered)
261346 in reply to 261301
Jim S.:
That would be jake.


And for the comments about pass by reference vs. pass by value:

Java passes *everything* by value. End of story.

Explanation in mind-numbing detail can be found here


Um, yeah. But I think the point of that article is that the value of a variable is a reference not the object itself.
Consider:

SomeMethod()
{
SomeObject foo = new SomeObject();
foo.setSomeProperty("bar");
/* 1 */
println(foo.getSomeProperty());
bar(foo)
/* 2 */
println(foo.getSomeProperty());
}


(Assuming SomeObject is a class with SomeProperty and associated getter and setter methods, and we have a method bar() that takes SomeObject)
Will print 2 give the same thing as 1?? Always? No Matter what bar() does?
If you pass by reference, any change made within a method is made to the Object referred by that reference.
If you pass by value, the object is 'cloned' (probably bad terminology), and a clone is passed to the method. That is, the method has its own COPY of the object, but not the object itself, and modifying it does not modify the original object.

Try passing an object in java to a method that modifies it, and you will find that the original object is modified. This is because java passes by reference, not by value. What the article you refer to is saying, is that the variable itself is a reference, and it is passed by its value. The article is merely being a little facetious.

NB: If you answered that the code may print something different the second time, you are only half right. The code doesn't compile - it's missing a semi-colon on the method call, but nice try.

Re: Java is Slow!

2009-05-12 19:26 • by far9999 (unregistered)
I don't think you are understanding the constant deal correctly. C++ has const correctness (http://en.wikipedia.org/wiki/Const_correctness) which both Java and C# are missing.

Basically in Java and C# there is no way to guarantee that a method you call doesn't mess with the internals of your object (unless your object is immutable). This is possible in C++.

Re: Java is Slow!

2009-05-12 19:26 • by Ralph (unregistered)
261348 in reply to 261342
LordOfThePigs:
Ralph:

perhaps I miss the point, but if you define a constant in c++ (ie use #define) is it not constant??
Forget const...

Not really, #define is preprocessor magic. This means that the preprocessor will basically copy whatever text is #defined everywhere it is referred to in the source code, before passing that modified code to the compiler. That works really well for int and other numeric types, but I'm unsure of how it really behaves with object or more complicated structures (my C++ is a bit too rusty).

IIRC, #define doesn't allow you to build a complicated object/structure and use the same copy multiple times accross your program. Due to the fact that it is just a preprocessor trick, you end up with many copies of the same data.


Point Taken, I've never used a Constant Object.
#define works nicely for my ints and strings....

Re: Java is Slow!

2009-05-12 19:32 • by Bimbo (unregistered)
261349 in reply to 261342
LordOfThePigs:
Ralph:

perhaps I miss the point, but if you define a constant in c++ (ie use #define) is it not constant??
Forget const...

Not really, #define is preprocessor magic. This means that the preprocessor will basically copy whatever text is #defined everywhere it is referred to in the source code, before passing that modified code to the compiler. That works really well for int and other numeric types, but I'm unsure of how it really behaves with object or more complicated structures (my C++ is a bit too rusty).

IIRC, #define doesn't allow you to build a complicated object/structure and use the same copy multiple times accross your program. Due to the fact that it is just a preprocessor trick, you end up with many copies of the same data.


#define is a preprocessor trick, but it is (reasonably) invisible to even the developer for simple uses (more complicated macros bring trouble very quickly - make sure to overuse brackets, and all that)

For more complicated constant Objects/structures (that you want lots of reuse), wouldn't a static class suffice? This would be reasonably constant (assuming you didn't allow it to be modified), or am I not switched on today??

Perhaps I'm clutching at straws....

Re: Java is Slow!

2009-05-12 19:38 • by Anon (unregistered)
TRWTFs here are:

a) They told Dick about the meeting
b) They let Dick within 10 miles of the offices on the day of the meeting

Either that, or they knew they were not going to get the contract, and they set Dick up so they could fire his ass.

Re: Java is Slow!

2009-05-12 19:39 • by dkf
261351 in reply to 261342
LordOfThePigs:
IIRC, #define doesn't allow you to build a complicated object/structure and use the same copy multiple times accross your program. Due to the fact that it is just a preprocessor trick, you end up with many copies of the same data.
If you're talking C, #define can't build objects because C doesn't have them. It can build shared structures, but that's not usually considered to be good style. C programmers tend to like their macro definitions to be simple and clear. (Unlike C++ templates...)
« PrevPage 1 | Page 2 | Page 3 | Page 4 | Page 5 | Page 6Next »

Add Comment