3 ms·

From the article: Slow startup -> 80ms. What are you using it for that 80ms is a problem? Memory usage: He explains why an AOT solution would use more memory.

From the article: Slow startup -> 80ms. What are you using it for that 80ms is a problem? Memory usage: He explains why an AOT solution would use more memory. What is the cognitive load with the JVM? You install it and the type 'java my.jar' BTW the JVM can reduce cognitive load hugely when it comes to profiling or debugging because of the tools.

eikenberry 10y ago
I've never seen 80ms in practice and he elides over how (even if true) it would only matter for command line programs as if those are rare, when in fact they are quite common. Only knowing "java my.jar" means you have zero knowledge about the nature of your language's run-time and having a good understanding of your languages run-time is necessary to write good code. The more complex the run-time of your language, the higher the cognitive load of that language. His discussion of memory use doesn't mention the pre-allocation of the heap for the JVM. The memory used by the application itself is irrelevant when the JVM is what is actually using the memory.
- floatboth 10y ago
  You can start up the VM in 80ms for sure, you'll just need much more time after that to load all the damn classes from the bloated libraries you're gonna use. (Especially terrible with functional runtimes like Clojure's.) > pre-allocation of the heap for the JVM Pre-allocation doesn't matter, it's not allocating physical memory?? The GHC Haskell runtime literally mallocs one terabyte when the program starts :D However OpenJDK/HotSpot's baseline memory usage is indeed higher than many other VMs'. Even if you compare with alternative JVMs: I tested a basic Jetty app — it used ~60 MB on JamVM, ~70 MB on OpenJDK.
usrusr 10y ago
Cognitive load might mean how you have to code completely against all assumptions, rules and conventions when you want control over things like memory locality for efficient caching and the like. Not a point I would stress too much, but it can be a valid consideration.

eikenberry 10y ago

I've never seen 80ms in practice and he elides over how (even if true) it would only matter for command line programs as if those are rare, when in fact they are quite common. Only knowing "java my.jar" means you have zero knowledge about the nature of your language's run-time and having a good understanding of your languages run-time is necessary to write good code. The more complex the run-time of your language, the higher the cognitive load of that language. His discussion of memory use doesn't mention the pre-allocation of the heap for the JVM. The memory used by the application itself is irrelevant when the JVM is what is actually using the memory.

floatboth 10y ago
You can start up the VM in 80ms for sure, you'll just need much more time after that to load all the damn classes from the bloated libraries you're gonna use. (Especially terrible with functional runtimes like Clojure's.) > pre-allocation of the heap for the JVM Pre-allocation doesn't matter, it's not allocating physical memory?? The GHC Haskell runtime literally mallocs one terabyte when the program starts :D However OpenJDK/HotSpot's baseline memory usage is indeed higher than many other VMs'. Even if you compare with alternative JVMs: I tested a basic Jetty app — it used ~60 MB on JamVM, ~70 MB on OpenJDK.

usrusr 10y ago

Cognitive load might mean how you have to code completely against all assumptions, rules and conventions when you want control over things like memory locality for efficient caching and the like. Not a point I would stress too much, but it can be a valid consideration.