Redpill me on Java speed

Redpill me on Java speed.

is it fucking slow?

Other urls found in this thread:

openjdk.java.net/projects/jdk9/
twitter.com/AnonBabble

I'd like to know as well

No. The JIT compiler is amazing. In rare circumstances it can even optimize hot section of code during runtime to be faster than a compiled language. While it is a little slower, the memory management overhead of large C/C++ projects tends to nullify real world gains, unless the programmer takes great care to actually manage the memory efficiently rather than just relying on RAII or similar techniques. Unless your code is runtime critical, java will be fine.

Is OpenJDK slower than Java?

Yes. Hobbyists open sores implementations of real professional software will always be much worse.

I don't know, but I'd imagine big companies pay to make java fast, so it'd be faster.

You shouldn't care unless you are having problems. Later you can switch with no effort. Premature optimization is the root of all evil

>Is an implementation slower than a language?
What the hell are you asking?

OpenjDK is reference implementation
openjdk.java.net/projects/jdk9/

Obviously he's asking if the open source implementation OpenJDK is slower than the proprietary version developed by Oracle

Why do you hate Java so much you keep making these hate threads?

Your bait is shit.

(part 1) Here's the redpill:
Java can be as fast as a compiled language like C and C++ in most instances but there are big asterisks next to this claim.
Java is first compiled into bytecode, and then further JIT compiled into native code, and if the JVM determines it necessary, to even further optimize sections of native code up to around the equivalent of gcc's "-O3" optimization. On the first pass (when a class is just loaded), the JVM will run at interpreted speeds because it has to interpret the bytecode first before it can JIT compile it. After that, after many iterations (usually thousands) of the code being called by the program, it'll determine critical areas in need of further optimization and then performs it. This is what's call the "warming up" phase of a JVM managed program; it's not running at it's full potential until after the optimizations are performed, and if a piece of code is rarely called, then potentially none are done because the JVM thinks what's the point?
Another aspect to Java's speed which actually makes it faster than C or C++ programmer written by a not very good programmer is how memory is allocated. Object creation in Java is extraordinarily fast. Much faster than calling "malloc/destroy" or C++'s "new/delete" operators. The reason being that the latter two are making OS calls to get/return memory, whereas the JVM is accessing memory it already has (it got this pool of memory when the program first started), and only calls the OS for more memory when it doesn't have enough. The JVM never releases memory back to the OS even after it removes objects because it keeps that memory for its own later use if need be. This is the reason Java applications appear to be bloaty in memory, but it's really an optimization for extremely fast memory access when creating objects and garbage collection. You can actually do this in C and C++ too, but the average Sup Forumsordo probably doesn't know how.

(part 2) With the above said, the advantages and disadvantages are clear. Java is excellent for programs that require high performance that run for a very long time because it can take advantage of all the JIT optimizations that would be immediately lost if the program were terminated. It's found a niche in server space since those apps can take advantage of its high performance given their nature without having to write difficult C++ code. Where Java sucks is in applications that require high performance but are constantly shut down and restarted. Think video games and mobile apps (which is why they moved away from JIT compilation in Android in favor of AOT in recent versions, because this shit was slow to start and would eat battery to get up to speed).

Um, HotSpot IS OpenJDK, but with some proprietary components with regard to some encoders, font and image rending, etc, not included in the open source version.

Faster than php and can be faster than c++ .

thank you for a quick rundown, user

The JVM startup is actually really fast, only a few milliseconds. And giving a running jvm code is really fast, things like nailgun, etc... are super fast. It's the loading of classes that causes big java programs like eclipse to take a solid 10 seconds to start up

It's pretty fucking slow, but odds are extremely high that it won't matter for whatever CRUD swill you're going to have to work on in a professional capacity.

All of the autists will pile in and go on about how "if you enable this JVM flag and compile with these specific settings, Java is as fast as C++!" You could also just write in C++ outright and not have to fuck around with any of that bullshit. The optimizations available are extremely situational and you'll know if they're valid in your use case.

Holy fuck are you new to this.
>if you enable this JVM flag and compile with these specific settings
That's C++ you retard. There are no compilation flags to set in Java unless you want to turn off the JIT altogether for testing purposes. And it's C++ where you have to know what flags to use in order to get out the maximum performance out of the program. What you stated is literally the opposite of reality.

>Faster than php
t. retard

Tell me more about php. Is it fast?

>Faster than malloc/free
Bullshit, OS'es tend to have preallocated pages in the heap as well. And they dont get released from the page table of the process during free , they do remain as part of the heap unless specific conditions are met.

Even while running on the interpreter its faster than PHP. PHP started out as a personal toy scripting language , i have no god damn clue on how it became the defacto backend language.

Still not as cheap as managing a memory slab within the process itself, bypassing all kernel calls to begin with other than when the slab is first allocated at runtime. There are obvious downsides to this (makes a Java program's memory bloat even if it's not actively using the memory for anything) but if you don't need fine-tuned memory efficiency then that's not a problem and may be even desirable in certain circumstances.
>Even while running on the interpreter its faster than PHP.
This. Bytecode is always more efficient to interpret than plain text. I don't know what the hell that user is talking about.

>t. clueless summerfriend

IMO, if you're going to use Java, use Kotlin. The benefits of writing code faster outweigh the small effect of all the hoops the compiler has to go through to make some of the Kotlin structures work in the JVM. You'll get slightly more memory usage in some cases and you'll cut many hours of boilerplate writing. And it works with Java libraries too... it's great.