4 ms·

Its very common to see people claiming that Java is faster than a native compiled application. But my gut feeling says otherwise. I don't know the Java interna

by bratao 13y ago

Its very common to see people claiming that Java is faster than a native compiled application. But my gut feeling says otherwise. I don't know the Java internals on Windows. But someone know why applications with graphical interfaces feels so slow ? My rough guess is that even if Java is fast for mathematical operations, it needs to call native libraries for drawing and this is expensive because of the isolation.

UK-AL 13y ago
It's a problem with Swing.
- pjmlp 13y ago
  It a problem with dumb programmers doing everything on the main UI thread.
  - eropple 13y ago
    And the Java core libraries encouraging it. I like a lot of the JVM, but Swing can go to hell; it makes doing the right thing more difficult than necessary in most cases.
remon 13y ago
This is almost certainly questionable programming rather than an issue with Java performance in general. Java is the language most beginning programmers start with and they'll do things like create wildly inefficient methods that they proceed to call from the UI thread and so on. Additionally the most used Java UI library (Swing) is not exactly known for its snappiness. The JNI interface introduces overhead but certainly not anywhere near the sort of overhead that should result in UI rendering issues. Long story short, sluggish UIs are bad programming and not related to the programming language they were created in.
- GlennS 13y ago
  I'd add that there aren't many good reasons why UI programming should be slow in any language on any desktop machine around today. You can draw tens of thousands of things on the fly in a web browser and have it appear instantaneous to a human.
hibikir 13y ago
While it's possible to write a Swing application that runs fast (starting fast is a different matter), it takes quite a bit of effort to do so, because the basic tools that it provides lead you towards slow applications and a lot of boilerplace. Any shop that ever did a bunch of Swing and cared about quality ended up writing their own layer on top of Swing that made those features easier to use, but they still require quite a bit of discipline. UIs is the kind of place where the whole reactive model actually works well. Create events, subscribe to events, and make each event handler run asynchronously. Use the dispatch thread for events that actually modify frontend-facing, elements, and everything else on background pools. So the broadly available toolset could only be used well by programmers that are better than the typical guy that was asked to write the UI, and we never got better tools.

by bratao 13y ago

UK-AL 13y ago

It's a problem with Swing.

pjmlp 13y ago
It a problem with dumb programmers doing everything on the main UI thread.
- eropple 13y ago
  And the Java core libraries encouraging it. I like a lot of the JVM, but Swing can go to hell; it makes doing the right thing more difficult than necessary in most cases.

remon 13y ago

This is almost certainly questionable programming rather than an issue with Java performance in general. Java is the language most beginning programmers start with and they'll do things like create wildly inefficient methods that they proceed to call from the UI thread and so on. Additionally the most used Java UI library (Swing) is not exactly known for its snappiness. The JNI interface introduces overhead but certainly not anywhere near the sort of overhead that should result in UI rendering issues. Long story short, sluggish UIs are bad programming and not related to the programming language they were created in.

GlennS 13y ago
I'd add that there aren't many good reasons why UI programming should be slow in any language on any desktop machine around today. You can draw tens of thousands of things on the fly in a web browser and have it appear instantaneous to a human.

hibikir 13y ago

While it's possible to write a Swing application that runs fast (starting fast is a different matter), it takes quite a bit of effort to do so, because the basic tools that it provides lead you towards slow applications and a lot of boilerplace. Any shop that ever did a bunch of Swing and cared about quality ended up writing their own layer on top of Swing that made those features easier to use, but they still require quite a bit of discipline. UIs is the kind of place where the whole reactive model actually works well. Create events, subscribe to events, and make each event handler run asynchronously. Use the dispatch thread for events that actually modify frontend-facing, elements, and everything else on background pools. So the broadly available toolset could only be used well by programmers that are better than the typical guy that was asked to write the UI, and we never got better tools.