4 ms·

The layers of abstraction for Java projects are getting almost comical. I'm sure there's good reasons behind it, but setting up logging for a Java backend a wh

The layers of abstraction for Java projects are getting almost comical. I'm sure there's good reasons behind it, but setting up logging for a Java backend a while back was pretty crazy. Ended up choosing logback as the logger implementation, sl4j as the logger abstraction layer, and then added log4j and commons-logging replacement jars that emulated those API's and redirected them to sl4j, which redirected them to logback.

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 ago
  I 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 ago
    it.s combination of factors: most custom software vendors combine pretty incompetent programmers (on average) with crappy inhouse frameworks built by these programmers.
  - kunley 16y ago
    Well 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 ago
  I 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...
deleted 16y ago
[deleted]
api 16y ago
What? KitchenSinkNuclearReactorDependencyInjectionSingletonFactoryObserver is excessive?

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 ago
I 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 ago
  it.s combination of factors: most custom software vendors combine pretty incompetent programmers (on average) with crappy inhouse frameworks built by these programmers.
- kunley 16y ago
  Well 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 ago
I 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...

deleted 16y ago

[deleted]

api 16y ago

What? KitchenSinkNuclearReactorDependencyInjectionSingletonFactoryObserver is excessive?