4 ms·
Yes and that's why many Java applications esp. in the corporate world are slow, contrary to the common belief. When I say many/most software written in Java is
by kunley 16y ago
Yes and that's why many Java applications esp. in the corporate world are slow, contrary to the common belief.
When I say many/most software written in Java is slow, people tend to laugh and direct me to the shootout benchmarks. This is actually sign of ignorance of what's really going on in the wild, which you can learn at operations btw. You don't put your stack of dependency injection, loggers and ORMs into a microbenchmark like shootout, while you do it for the typical Java web application. The insane amount of calls on stack - tens of thousands and above, and the insane amount of small classes which all have to be managed by classloader, takes your app out of cpu cache, takes your files out of os file cache, pumps the enormous memory usage, stresses the gc and causes your JVM to have its crawling moments - or crawling standards.
So it's not that JVM itself sucks, but the stuff you typically want to run on it makes it a horror.
- WTFpeepul 16y agoI respectfully disagree that frameworks are causing corporate java applications to exhibit poor performance. I've never seen evidence of it. The extra layers of abstraction added by the framework certainly do slow things down, but in the corporate world it's the database that has the biggest impact on app performance. The microseconds spent executing a few extra commands is negligible. Bad programmers will always create poorly performing software and the corporate world is full or bad programmers who are using frameworks. To place the blame on the frameworks and not the programmers is misguided in my opinion.
- dfox 16y agoit.s combination of factors: most custom software vendors combine pretty incompetent programmers (on average) with crappy inhouse frameworks built by these programmers.
- kunley 16y agoWell I have seen such evidence a couple of times. Some profiling of code using huge library stacks gave really surprising results. I think it's worth considering that there's no such thing as "microsecond spent on few commands" alone. Every extra vm command competes with others in the cpu cache, similar for classes loaded in the os file cache. It seems to matter when you have thousands of typical calls on a stack instead of, say, dozens.
- sesqu 16y agoI was suddenly reminded of this blog post from 2006, a screenshot of the stack of a small web app: http://ptrthomas.wordpress.com/2006/06/06/java-call-stack-from-http-upto-jdbc-as-a-picture/ http://ptrthomas.wordpress.com/2006/06/06/java-call-stack-fr...