6 ms·
On a $50/mo Azure VM running Windows Server I’m able to run a jar via java.exe that prints a string to stdout and exits - in about 160ms end-to-end in a warm-is
by DaiPlusPlus 4y ago
On a $50/mo Azure VM running Windows Server I’m able to run a jar via java.exe that prints a string to stdout and exits - in about 160ms end-to-end in a warm-ish environment (Prefetch, IO caching, etc)
Edit: Now it’s down to 80ms - I guess at this scale it’s hard to pin down.
- MaxBarraclough 4y agoHow about 'typical' application code though? The JVM does bytecode verification for every class it loads, for instance.
- kaba0 4y agoIt loads classes lazily, so your program can start up at `main` very fast, and you only pay for what you use. This might cause some application feature to start up a bit slower on first run, but the byte code format is very compact and can be parsed in a single pass, so I don’t think it would be significantly slower than ordinary machine code loading.
- MaxBarraclough 4y ago> It loads classes lazily, so your program can start up at `main` very fast, and you only pay for what you use Right, but large Java programs use huge numbers of classes. They may load thousands of classes just during start-up. > the byte code format is very compact and can be parsed in a single pass, so I don’t think it would be significantly slower than ordinary machine code loading That's what I was wondering about. There used to be a flag in OpenJDK to disable bytecode verification to improve start performance, but it was deprecated in JDK 13 [0] and I think it's since been removed entirely. Its removal is understandable but I still wonder about the performance impact. [0] https://www.oracle.com/java/technologies/javase/13-relnote-issues.html https://www.oracle.com/java/technologies/javase/13-relnote-i...