5 ms·
But noone cares about hello world. You're not building hello-worlds in real life. Slow startup time is a problem in automated testing of big codebases - when y
by pkolaczk 5y ago
But noone cares about hello world. You're not building hello-worlds in real life.
Slow startup time is a problem in automated testing of big codebases - when you aim to test the whole codebase, but each test alone does not stress any code path hard enough for the hotspot compiler to kick in. So basically most of your Java code in testing runs in interpreted mode, which is like 20x-100x slower than properly compiled and optimized C/C++/Rust.
- kaba0 5y agoThat’s just not how it works. If no code path gets run enough times, then frankly, it simply doesn’t matter, they could have been written in bash and still be “fast enough”. Like, I can’t fathom a program that doesn’t have loops where the actually important part happens. You simply can’t write enough “linear” code to make a modern CPU sweat even just a little. And if you do have said loop, than it will be JIT compiled.
- pkolaczk 5y agoBut it's not just interpreting linear code. It is also classloading which involves a non-trivial amount of work before any code in a class can even run. Also I never said the testing code doesn't have any loops. There often are loops but they need to run for a really long time until hotspot kicks in. So if you lose a few tens of millisecond here and there in a single test, you will get minutes or hours in total in a codebase that has hundreds of thousands tests. And it gets terribly worse if many of your tests are end-to-end tests that e.g. launch new JVMs.