This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (5)
- # babashka (1)
- # beginners (193)
- # calva (79)
- # cider (18)
- # clara (4)
- # clojure (38)
- # clojure-europe (12)
- # clojure-france (8)
- # clojure-nl (12)
- # clojure-sweden (1)
- # clojure-uk (50)
- # clojurescript (37)
- # conjure (30)
- # cursive (3)
- # data-science (2)
- # datalog (7)
- # datomic (12)
- # events (2)
- # expound (3)
- # figwheel-main (1)
- # fulcro (45)
- # graalvm (1)
- # jobs (1)
- # jobs-discuss (11)
- # luminus (1)
- # malli (5)
- # off-topic (32)
- # reagent (6)
- # reitit (32)
- # shadow-cljs (25)
- # spacemacs (2)
- # sql (22)
- # vim (6)
I guess general purpose JVM? I know you're doing great work with command line apps, and for the same reasons it seems like a nice fit for Lambda/FaaS. I was browsing the Graal website and they make a lot of claims about great performance but it's not so clear what the trade-offs are.
IIRC some people mentioned that GraalVM is good for startup (i.e. good for short-running apps that are used more or less often) but bad for long running applications because it can't do the same runtime optimizations the regular JVM can do.
I know some people using graalvm as their default jvm for work and I think things mostly just work.
Ah, OK, I stand corrected then. I was almost certain that using GraalVM always means ending up with a native image.
Nope. Graalvm is a jvm where the jit(? Might be a different part I'm thinking of) is written in java rather than natively. That's the big sell really. Writing optimizations in java is much easier.
I think that's a "big sell" for JDK implementors; not so much for consumers / regular programmers
I don’t think they are there yet. The original C2 compiler has decades of development and optimization behind it. Do you have links to any trustworthy resources demonstrating the performance improvements?
Nope. I've heard the same as you. Although graalvm has some 1% speed up charts on their site, I've never investigated. The value seems to be that they can bring those optimizations to ruby etc. And they're making other languages as fast as java.
I think one could hypothetically write some optimizations which targeted clojure specifically, but I don't think anyone is doing that.
Except the fast feedback loop through repl-driven development, don't you agree that the data-oriented aspect of Clojure (working with .edn) is a superpower? I have a sql server stored procedure returning about 500 properties in a map, imagine having to create an object that represents this data in e.g C# or Java for test purposes. What would you do? If you have transformation logic, how do you write test-cases in a practical way? "I have this input, and this is the expected output that we put on a MQ". 🙂.
> imagine having to create an object that represents this data in e.g C# or Java for test purposes. What would you do? I would just create a map.
I think Hibernate supports executing arbitrary queries and returning a list of maps. A quick search suggests that's correct. But of course I agree with your statements anyway. :)
@p-himik this map is also nested, how do you represent this data in C# or Java? Maps in maps, and that comes with some semantics that "hides" the actual data shape such as Put... etc (maybe it's better in 2020): It's of course doable in C# and Java, but there is some more work and some more "stuff" that one has to think about (Imo) 🙂
Yeah, i'm refering to JSON or something else that can be nested in my previous reply. My bad.
Then yeah, maps of maps. Not different from Clojure in terms of the data shape. But quite a bit more cumbersome, mostly because of all the typing.
Exactly. In Clojure you can work with data, which you can copy around. Of course there are trade-offs, but for some domains, e.g where you transform X to Y most of the time... it's quite nice to use something that makes this kind of thing practical
@michael.e.loughlin I don't see this "great performance improvement" on most of my projects. What I do see is about 15% increase in memory usage.
That's one of the reasons I prefer OpenJ9 JDK - memory consumption is really low there. It's a pity that ClojureScript compiler does not work that well with it :(
This is interesting: > memory consumption is really low there Compared to what? Do you have any numbers to show?
For a rough comparison, while I'm developing Chlorine (a package for the Atom editor, written in ClojureScript) I mostly use OpenJDK because compilation of CLJS in OpenJ9 sometimes give me strange results. So, after about 30 minutes, OpenJDK is showing 11% of my memory is being used for the Shadow-CLJS
Most of the time, I can't have 11% of my memory being used so I change to OpenJ9. The same process, same arguments, is now showing 6.5% memory usage. There's also this article https://technology.amis.nl/2018/12/09/jvm-performance-openj9-uses-least-memory-graalvm-most-openjdk-distributions-differ/, that while a little old it does reproduce what I see on my development machine 🙂
Here's at least something: https://www.royvanrijn.com/blog/2018/05/openj9-jvm-shootout/#comment-3904117577 I sympathise with this comment: > Without actually knowing what youre doing, sure, the default settings on different JVMs can result in different heap sizes with the same workload.... But it wont have anything to do with one or the other being more efficient with memory.
@ this is what people always say when I show these comparisons. The thing is, I've tried lots of different settings - none was able to beat OpenJ9
Maybe it works well for certain kind of applications. I might try this on some of my own projects to see how it compares