[Mercurial]

They keep telling me that Java is slow and C++ is fast, that the Earth is round, God listens, and that you can't get pregnant if its your first time. It gets in your ears that much that you take it as a fact.

Speed is relative. When choosing a language you're about to develop software in, you usually pick the one that makes your life easier. How about speed? All the 'Java is slow' talk, got me thinking about this. Most desktop applications written in Java will have no problem running. Well... When do we encounter problems then(skip the heavy mathematical calculations topic that are used in 3d games)? I'm interested in oppinions about other languages aswell, I took Java as an example.

[moopet]

When we code for limited platforms - limited in terms of memory or processing ability. Even in terms of non-volatile storage. Embedded systems. Anywhere where the overhead of the platform becomes more than a tiny fraction of the resource expense of the application.

But it's not all just that. For some languages like high-level ones that are not interpretive or compiled to byte-code, the expense of having a massive supporting library is offset by the fact that it's probably written better than you could have written it while putting together your application. Any slowness in that case is likely to come from the library's generalisation and
error-checking.

Most of us will never have to care, I don't think. The only time I see this as an issue is with web frameworks rather than the language itself. For instance, I'm using Django for a project right now and it's noticably slower at some tasks than a light framework like, say, Codeigniter. But it's superior in almost every other respect.

This is not a coherent reply, I fear I'm rambling.

[macosxnerd101]

The issues with the speed of Java may have been an issue in earlier versions on less powerful machines, but on any relatively modern computer, you shouldn't notice the difference in performance time between C++ and Java. The same more or less applies to most every language I can think of. Certain languages may take a few nanoseconds longer to run or hog a few more bytes of memory, but nothing significant today.

Of course, if you write bad code, no language is going to change the ramifications of such.

[Mercurial]

Rambling can't be bad.

moopet, on 21 August 2010 - 10:44 AM, said:

But it's not all just that. For some languages like high-level ones that are not interpretive or compiled to byte-code, the expense of having a massive supporting library is offset by the fact that it's probably written better than you could have written it while putting together your application. Any slowness in that case is likely to come from the library's generalisation and
error-checking.

Can you elaborate that?

[moopet]

Mercurial, on 21 August 2010 - 06:04 PM, said:

Rambling can't be bad.

moopet, on 21 August 2010 - 10:44 AM, said:

But it's not all just that. For some languages like high-level ones that are not interpretive or compiled to byte-code, the expense of having a massive supporting library is offset by the fact that it's probably written better than you could have written it while putting together your application. Any slowness in that case is likely to come from the library's generalisation and
error-checking.

Can you elaborate that?

Well libraries tend to have been peer-reviewed during development and are usually pretty good code. If you look at the source for a simple function like strcmp in C, for example... well when I look at them I think I've been coding C since I was a kid and I stop and think "d'oh, why didn't I think to do it that way?" which is the side of them which is written well. They're likely to be slower though because in your application you know the constraints. You might know for instance that at no point in the code will you ever pass in invalid input to the function because the inputs are cleaned elsewhere, or that it doesn't have to cope with unicode strings or i18n or anything like that. So your version wouldn't have the overhead of checking to see what was what, or putting everything in try... catch blocks and storing error messages and so forth.

It's powerful in Java, for example, with automatic garbage collection so you don't have to worry about keeping track of everything and can just get on with writing code, but all that is done behind the scenes whether you need it or not. The higher-level the language, the greater the abstraction but the more that has to go on inside that abstraction layer that your particular app doesn't need.

[macosxnerd101]

Take the java.io File I/O package for example. It comes with a bunch of tools for reading and writing to Files using streams. Now, you could write your own File I/O tools without the error checking that may be slightly faster than the ones in the java.io package, but would you really want to? Do you trust yourself more than the Sun developers who invented the language? I wouldn't put that much trust in myself, and on top of that, it's a waste of development time. No reason to reinvent the wheel when it already exists for you.

We usually give a similar answer to people who ask: why use a high level language (usually followed by a "with OOP" clause) and not just hardcode in assembly? Assembly is faster, right? This may be true, but as computers advance, the runtime gain becomes increasingly marginal. On top of that, high level languages make it easier to write the code, allowing you the developer to focus on abstraction and algorithm development, and write less and overall more maintainable code than with assembly.

[Mercurial]

@moopet Thanks. I never thought about error checking and all the stuff on the side.

@macosxnerd101 Exactly, and I'm aware of that I probably (for sure actually) couldn't write it better than Sun developers. I was just wondering how it could be an offset to have something that is most likely written better than your version, plus that it can slow things down.