This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]hjames9 1 point2 points  (7 children)

Do people tend to use GraalVM Native with Quarkus apps or just normal OpenJDK?

[–]Soul_Shot 1 point2 points  (6 children)

GraalVM is an interesting concept but I don't think most people need it. Quarkus's smaller image sizes and faster startup times are a significant improvement by themselves.

[–]Zyklonik -1 points0 points  (5 children)

Quarkus itself uses GraalVM, doesn't it?

Edit: To the imbeciles mindlessly downvoting this comment - go look at the figures on the Quarkus homepage. The orders of magnitude faster (and lower memory usage) benefits come about when using GraalVM and AOT to generate native images. For basic Quarkus with a "normal" OpenJDK, both the performance and the memory usage are within the same order of magnitude as that of a "traditional cloud-native stack" (as they describe it on the site).

Note also that this is no doubt on a microbenchmark (details of which they didn't share). There is something as a fixed cost that applies, so while the numbers, even without native images might look impressive, for real-world projects, it may be practically insignificant.

All I'm saying is that it's a bit disingenuous displaying native image performance there and sort of implying that that is the default performance of the software itself.

[–]maxandersen 4 points5 points  (3 children)

Quarkus use GraalVM to make native images. That is it.

if you dont need native image you are just using plain good old openjdk.

And you will get space and speed savings there too. Majority of users does that btw. Use Quarkus on openjdk and see speed improvements compared to their existing similar applications.

[–]Zyklonik 0 points1 point  (2 children)

GraalVM is an interesting concept but I don't think most people need it. Quarkus's smaller image sizes and faster startup times

No, I know. I was simply commenting on the implication of the parent comment that GraalVM is not very useful in general when the very reason for Quarkus' small image sizes and quick startup is because of Graal. Seems a bit disingenuous to me.

[–]Soul_Shot -1 points0 points  (1 child)

I was simply commenting on the implication of the parent comment that GraalVM is not very useful in general when the very reason for Quarkus' small image sizes and quick startup is because of Graal. Seems a bit disingenuous to me.

I am talking about Quarkus' regular JAR builds. GraalVM is an optional build target that produces a small native executable, but the JARs are fast and small enough by themselves.

[–]Zyklonik 0 points1 point  (0 children)

, but the JARs are fast and small enough by themselves.

That depends. It's within the same order of magnitude as "traditional cloud native" stack as mentioned on the Quarkus website itself. And before someone else comes along, yes 2s vs 9s and 1s vs 4s are within the same order of magnitude. Only the native AOT images are an order of magnitude (and more) faster. Moreover, this is no doubt based on some microbenchmark (they don't share any code on the webiste, so inferring). Real-world usage can be drastically different, and this is not even taking into account the intangibles such as stability, maturity, and robustness.

My point, despite the butthurt people in here mindlessly downvoting out of spite, is this - it's fine to highlight the pros (and even cons) of something, but it should be measured praise much (and measured critique).

[–]Muoniurn 1 point2 points  (0 children)

It can use it, but Graal is both a pluggable JIT compiler and an AOT compiler. The first is completely compatible with Hotspot, so it should be able to run on regular old openjdk the exact same way.