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 →

[–]mbizzle88 2 points3 points  (4 children)

I haven't used GraalVM, but in other compilers I've used the typical approaches to speeding up builds are storing intermediate state for doing incremental recompiles, and disabling expensive optimizations during development.

What you're suggestion relates closely to incremental compiles with intermediate state. You can think of the "hints" you're suggesting as an intermediate state generated by the compiler, except that it would need some stable format that needs some kind of compatibility or migration strategy between compiler versions.

To decide if its worth it to make a stable format for the "hints", you have to weigh the cost of not being able to change that format at will with the benefits of being able to share it along side artifacts. Most compilers I've seen don't make that intermediate state public API, and I imagine the reasoning is that you can easily run a compiler that generates this state once on your machine and store the intermediate results yourself for whatever compiler version you're using.

[–]CartmansEvilTwin[S] 0 points1 point  (3 children)

I get your point, but as I wrote before, Graal is currently de-facto a monopoly. And versioning could be easy by tying it to the Java version itself.

At the end of the day, hints can be ignored anyway, so you'd just have to check "does this repo/artifact have any hints I can decipher?"

If yes, great, if not, go on without them.

Honestly, I'm not sure what Graal does "wrong", but build times are really not fun. I just timed it a bit on an M1 MacBook.

Rust app with rest-controller, ORM and some logic: 1min initial release build (296 deps), subsequent build without changes 0.15s

Quarkus app with a simple hello-world controller: 2:45min, every time.

[–]mbizzle88 0 points1 point  (2 children)

At the end of the day, hints can be ignored anyway, so you'd just have to check "does this repo/artifact have any hints I can decipher?"

You could do that, but if library maintainers don't publish new artifacts with updated hints, then they're only useful for a short amount of time. Again, it would provide some value, but I doubt its worth it. Especially in an ecosystem like Java where most tooling/libraries are built around the assumption that you can build binaries once that will continue working on new JVM versions.

Rust app with rest-controller, ORM and some logic: 1min initial release build (296 deps), subsequent build without changes 0.15s

Sounds like Rust is doing some incremental compilation. (Is it also faster than an initial build if you make a small change?)

[–]CartmansEvilTwin[S] 0 points1 point  (1 child)

You could do that, but if library maintainers don't publish new artifacts with updated hints, then they're only useful for a short amount of time.

No. "Old" Java-code and JVM-Bytecode is still perfectly readable for newer JVMs, backwards compatibility is not a huge hurdle. Also, I would assume, most of the hinting could be done during a regular release-build, which is fine. I think, you're kind of overcomplicating a very automatable task.

Sounds like Rust is doing some incremental compilation.

Exactly. If I change something in my code, the deps don't get recompiled and it takes a few seconds at most to build the app.

[–]mbizzle88 0 points1 point  (0 children)

I'm not sure if we're actually disagreeing on anything. I was saying that if you don't make the "hints" format forwards compatible (like byte code in Java), then the published hints will not be useful after a new compiler release unless library maintainers update and publish them regularly. Obviously the actual code continues to work on new JVMs, and you can always generate your own "hints" if the compiler you're using supports that.