Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Command-line apps with Clojure and GraalVM: 300x better startup times

astrecipes.net

Post reply on HN
Print view View original

51–60 of 66 posts

Re: Command-line apps with Clojure and GraalVM: 300x better startup times

#51

Post by thomaswue »

cutler wrote: post #37

"6G to 8G RAM" to compile. A real win then.

This compilation step is only required once when you release your tool. The resulting binary is then providing fast startup and low memory footprint whenever users invoke your tool. So, yes, it is a real win if your tool gets used more than once.

Re: Command-line apps with Clojure and GraalVM: 300x better startup times

#52

Post by jacques_chester »

letientai299 wrote: post #4
Cthulhu_ wrote: post #2

Generally speaking, startup times for Java / JVM based apps should be worked on next by the teams behind it; in the container age, fast startup is a good thing. I know the JVM itself starts up fast enough, but then going with e.g. Spring on top of that just adds a minute of startup time - and I've no clue what it's doing, I wouldn't think loading config, registering services and opening up a servlet thingy would take…

I think the startup time in Spring got that long due to resolving graph of dependencies at runtime.

It's disk I/O. The JVM basically loads classfiles one at a time. When you use Spring Boot, you are asking Spring to pull in potentially thousands of such classes.

Preliminary tinkering by Spring folks shows Graal having a substantial impact there too.

Re: Command-line apps with Clojure and GraalVM: 300x better startup times

#53

Post by xfer »

thomaswue wrote: post #51
cutler wrote: post #37

"6G to 8G RAM" to compile. A real win then.

This compilation step is only required once when you release your tool. The resulting binary is then providing fast startup and low memory footprint whenever users invoke your tool. So, yes, it is a real win if your tool gets used more than once.

Or use like lots of other languages that provide all these "wins" without having to provide justifications like "only for release build and if your tool gets used more than once".

Re: Command-line apps with Clojure and GraalVM: 300x better startup times

#55

Post by liveoneggs »

alain_gilbert wrote: post #46
me_again wrote: post #17

"So you have no excuses not to build your CLI tools in Clojure now." Except that the toy program is 25MB and takes multiple minutes to compile...

lol, and I thought my 5MB golang binary was huge!

strip it

Re: Command-line apps with Clojure and GraalVM: 300x better startup times

#56

Post by alain_gilbert »

liveoneggs wrote: post #55
alain_gilbert wrote: post #46

Earlier quoted context omitted.

lol, and I thought my 5MB golang binary was huge!

strip it

I use upx if I don't plan on having binary patch updates.

But I wanted to be fair with the article.

Well, to be fair with Go, I should say 2MB for an hello world app like the one they have.

Re: Command-line apps with Clojure and GraalVM: 300x better startup times

#57

Post by chrisseaton »

codedokode wrote: post #54

Why cannot Java probuce binaries that can be mapped into memory and shared like native executable files? It could solve the startup time problem. Google even had to invent a zygote process in Android to make apps start faster.

> Why cannot Java probuce binaries that can be mapped into memory and shared like native executable files? It could solve the startup time problem.

It can. That’s what this article is about.

Re: Command-line apps with Clojure and GraalVM: 300x better startup times

#58

Post by msgilligan »

kodablah wrote: post #48
zbentley wrote: post #47

Earlier quoted context omitted.

> Proprietary software is non-free computer software for which the software's publisher or another person retains intellectual property rights—usually copyright of the source code... https://en.wikipedia.org/wiki/Proprietary_software

Which is the case here for Graal (there are differing definitions of "free"). From your link: > While most proprietary software is distributed without the source code, some vendors distribute the source code Source code available, or even under an open source license, does not change whether it is proprietary. Not sure this is the best place to discuss the nuances of these terms. Essentially, they retain the IP, have…

You can use it under the terms of GLP 2 w/classpath exception, which is what Google eventually decided to do. I'm not defending Oracle's business practices, just saying that Java and Graal are both Open Source™ and could be maintained by the community completely free of Oracle under the terms of GPL 2 w/classpath exception.

Re: Command-line apps with Clojure and GraalVM: 300x better startup times

#59

Post by ofrzeta »

Skunkleton wrote: post #18
prudhvis wrote: post #10

Earlier quoted context omitted.

Thank You. This is a good video to drive the massage.

Nothing like a good massage!

related: "Why is the title of the book The Medium is the Massage and not The Medium is the Message? Actually, the title was a mistake. When the book came back from the typesetter's, it had on the cover 'Massage' as it still does. The title was supposed to have read The Medium is the Message but the typesetter had made an error. When McLuhan saw the typo he exclaimed, 'Leave it alone! It's great, and right on target!' ..." https://en.wikipedia.org/wiki/The_Medium_Is_the_Massage

Re: Command-line apps with Clojure and GraalVM: 300x better startup times

#60

Post by yogthos »

xfer wrote: post #53
thomaswue wrote: post #51

Earlier quoted context omitted.

This compilation step is only required once when you release your tool. The resulting binary is then providing fast startup and low memory footprint whenever users invoke your tool. So, yes, it is a real win if your tool gets used more than once.

Or use like lots of other languages that provide all these "wins" without having to provide justifications like "only for release build and if your tool gets used more than once".

I spend most of my time actually programming in the language, not compiling it. So, I'm going to optimize for that, but to each his own I suppose.
Post reply on HN