✔ Java Anwendungen wieso grundsätzlich langsam?

[zeja]

Ich glaube solche verallgemeinernden Aussagen kann man einfach nicht treffen.

Jede Sprache hat so ihre Vor- und Nachteile und je nach Einsatzzweck muß man dann entscheiden welche Sprache man verwendet.

In vielen Bereichen ist Java auch nicht langsamer oder nur so minimal dass die Vorteile von Java C++ übertreffen.

In jedem Fall wird Java im Moment von Release zu Release ein Stückchen schneller (behauptet Sun zumindest). Und im leere Schleifen durchlaufen ist Java wirklich spitze (http://www.javaspecialists.eu/archive/Issue158.html)

Dann gibt es mittlerweile Real Time Specifications für Java und so weiter, und so weiter...

 

[Grimreaper]

Kann man als Fazit sagen, dass Java nie in der Lage sein wird, so schnell zu arbeiten wie z. B. C++, und man daher bei komplexen Anwendungen lieber auf andere Programmiersprachen ausweichen sollte?

Oder wird das in der nächsten Zeit kein Problem mehr sein, denn neue Möglichkeiten werden entwickelt oder intelligente Verfahren eingesetzt: Threads

Das Java theoretisch nie so schnell sein wird wie C++, kann man als Fazit festhalten. Genauso wie man mit ASM theoretisch besser optimieren kann als mit C/C++. Praktisch uebersieht man dabei aber so viel, dass der Compiler durchaus mithalten kann. Siehe z. B. Raymond Chen's Artikel zu C vs .Net: http://blogs.msdn.com/oldnewthing/archive/2006/07/31/684105.aspx.

In wie weit welche Sprache fuer einen taugt muss man von Fall zu Fall entscheiden.

 

[Oliver Gierke]

Na dann werf ich doch mal diese Links in die Runde:

http://paulbuchheit.blogspot.com/2007/06/java-is-faster-than-c.html
http://kano.net/javabench/
http://www.oreillynet.com/xml/blog/2006/01/native_code_no_longer_any_fast.html

So, nun fresst mich

Nettes Zitat:

Two things. First, static compilation is not a magical process. Java and C eventually become processor-specific bytecode; they just do it at different times. C does it at compile time, Java does it all at application startup (JIT) or in bits and pieces at runtime (Hotspot). It may also be possible for Hotspot to make decisions at runtime about how to use registers and memory that are better than what can be known at compile-time. Maybe. At any rate, when I see people running their Java code through GCJ and then complaining it's not any faster, it serves to make my point that all they're doing is moving the compile time.

Second: context. If C is arguably faster than Java, it's definitely harder to write and less productive. Each language chooses its own sweet spot. Assembly is clearly faster and harder than C. Ruby is (probably) slower but arguably easier (more productive) than Java. What matters for your application?

Selbst, wenn man annimmt, C sei im Schnitt 10% flotter als Java. Wer möchte denn bitte Serveranwendungen in C schreiben? Fatclients nur für ein OS?

Ich vermute 95% der Anwendungen, die in Java geschrieben werden sind keine Fraktalberechnungen oder Gerätetreiber, sondern Unternehmenskritische verteilte System, Webapplikationen usw. In denen sind Datenbankzugriffe z.B. um Welten teurere als es der Unterschied zwischen und C jemals war. Von der größeren Komplexität von C(++) Anwendungen mal ganz zu schweigen.

Wie gesagt, ich sehe definitiv Gebiete in denen ich C(++) den Vorzug vor Java geben würde. Allerdings ist erstens die pauschale Aussage, C(++) sei immer schneller als Java grundfalsch und zweitens wärees, selbst wenn es war ist, für große Teile der Anwendungslandschaft vollkommen irrelevant.

...es gibt viele Stufen grau, werden nicht farbenblind...

Freundeskreis - Die Revolution der Bärte

REINHAUN!

 

[Thomas Darimont]

Hallo,

der dynamische Hotspot Compiler hat in manchen Situationen mehr und bessere Möglichkeiten Maschinen code erzeugen als ein statischer Compiler wie der gcc etc., denn in die Optimierung geht nicht nur die statische Programminformation ein sondern auch dynamische Laufzeitinformationen. So macht es manchmal Sinn, ein Teil des Maschinencodes nach einer Zeit wieder zu deoptimeren um mit zusätzlichen statistischen Ausführungsinformationen den Code noch besser optimeren zu können.

Mehr dazu gibts hier:
http://java.sun.com/javase/technologies/hotspot/
http://java.sun.com/docs/hotspot/HotSpotFAQ.html
http://openjdk.java.net/groups/hotspot/
http://weblogs.java.net/blog/kohsuke/archive/2008/03/deep_dive_into.html

Ansonsten würde ich mal behaupten, dass wenn man eine träge und langsame Java (Swing, SWT/JFace) UI erlebt, diese einfach ungünstig Implementiert ist. (Langsame java UIs trifft man leider ziemlich oft an, aber das liegt in der Regel nicht an der verwendeten Technologie...)
Dazu zählen dann solche Antipatterns wie falscher / verschwenderischer Umgang mit Ressourcen (Bildern, Texten, Schriftarten), nicht deregistrierte Event Handler, zu viele Events erzeugen, langlaufende Aktionen im UI Code, zu viele Repaints, synchrones Ressourcenladen beim Bootstrap / Startup - überhaupt Ressourcen immer gleich alle auf einmal laden, selbst wenn der Teil noch gar nicht benötigt wird..., zu alte Java Version, zu alte Grafiktreiber etc. Da kann
man eine ganze Menge kaputt machen. Richtig performante UIs zu bauen stellt auch heute eine große Herausforderung dar bei der man viel Wissen und Erfahrung mitbringen muss.

Wie mans richtig macht sieht man u.a. hier:
Das gilt so IMHO übrigens für so ziemlich jede andere Technologie mit der man UI's baut, sei es nun WPF / Silverlight oder Flex.

Hier noch ein paar Links für modernes UI Design mit Java:
http://community.java.net/javadesktop/
https://aerith.dev.java.net/
http://www.curious-creature.org/category/swing/
http://www.curious-creature.org/category/swing/page/2/
http://www.amazon.com/gp/product/01...mp=1789&creative=9325&creativeASIN=0132413930
http://www.curious-creature.org/category/swing/
http://weblogs.java.net/blog/chet/
http://weblogs.java.net/blog/joshy/

Ich denke, dass die heutigen und zukünftigen JVMs (das ist die Ausführungsplatform für Java) auf jedenfall für die meisten Anwendungen schnell genug ist.
Weiterhin ist Multicore mittlerweile Standard - es geht nun nicht mehr darum den Programmcode soweit zu optimieren, dass er auf einem Prozessor möglichst gut läuft, sondern darum das der Code auf mehreren Prozessoren/Kernen gleichzeit möglichst viel parallel arbeiten kann. Hier geht es dann mehr um clevere Algorithmen mit guter Unterstützung für Parallelisierung und geschicktem Einsatz von Locking, als um kleine Micro-Optimierungen und das kann man mit einer Technologie wie Java auf der JVM meiner Erfahrung nach sehr gut.

Gruß Tom

 

[Norbert Eder]

Dazu zählen dann solche Antipatterns wie falscher / verschwenderischer Umgang mit Ressourcen (Bildern, Texten, Schriftarten), nicht deregistrierte Event Handler,
zu viele Events erzeugen, langlaufende Aktionen im UI Code, zu viele Repaints, synchrones Ressourcenladen beim Bootstrap / Startup - überhaupt
Ressourcen immer gleich alle auf einmal laden, selbst wenn der Teil noch gar nicht benötigt wird..., zu alte Java Version, zu alte Grafiktreiber etc. Da kann
man eine ganze Menge kaputt machen.

Grundlahme Anwendungen, gerade im Java-Bereich, gibt es zur Genüge (siehe das Oracle-Verwaltungs-Teil). In den meisten Fällen dürften allerdings die von Thomas genannten Punkte zutreffen. Anmerken wollte ich dazu, dass sich dies auf ALLE UIs (unabhängig der verwendeten Technologie) bezieht. Gerade zu häufige Repaints/Refreshes, tausende Event-Calls machen Oberflächen oft unnötig langsam.

Richtig performante UIs zu bauen stellt auch heute eine große Herausforderung dar bei der man viel Wissen und Erfahrung mitbringen muss.

Kann ich absolut bestätigen. Mit den richtigen Handgriffen, ein paar Umstellungen und einem eventuell notwendigen Redesign lassen sich meist 30+ Prozent an Leistung aus jeder UI-Anwendung herausholen (eine entsprechende Größe angenommen).

Wie mans richtig macht sieht man u.a. hier:
Das gilt so IMHO übrigens für so ziemlich jede andere Technologie mit der man UI's baut, sei es nun WPF / Silverlight oder Flex.

Gerade bei Technologien wie WPF/SIlverlight (Flex kenne ich zu wenig) ist es sehr wichtig zu wissen was man tut. Fundiertes Wissen über das Layout-System muss vorhanden sein, sonst wird die Oberfläche NIE performant.

 

[Grimreaper]

@zeja
Wenn man mit Pointern arbeitet, kann der Compiler eher weniger optimieren. Das ist einer der Gruende, warum Fortran ein wenig besser optimiert als C++.

@Thomas
Mir scheint es so, als ist es mit Java fast unnoetig schwer eine performate UI zu erstellen (gerade was AWT, Swing angeht). Traege UI ist mir z. B. unter .NET nie so aufgefallen. Irgendwoher muss ja Javas schlechter Ruf herkommen

 

[zerix]

Irgendwoher muss ja Javas schlechter Ruf herkommen.

Na der kommt daher, dass Java mal langsam war. Das ist aber schon lange her. Swing war auch mal recht langsam, aber da hat sich mittlerweile auch eine ganze Menge getan.

MFG

Sascha

 

[Norbert Eder]

Na der kommt daher, dass Java mal langsam war. Das ist aber schon lange her. Swing war auch mal recht langsam, aber da hat sich mittlerweile auch eine ganze Menge getan.

Mir ist aber bis dato noch keine Java-UI untergekommen, die annähernd so performant ist, wie eine Windows Forms App (.NET) oder beispielsweise auch WPF.

Ich hab hier beispielsweise RSS Owl laufen. Setzt doch eher neuere Techniken und Technologien ein, aber dennoch: es ist lahm, was mir eigentlich nicht begreifbar ist, da das Teil keine großen Datenmengen haltet, sondern lediglich die letzten paar Einträge eines Blogs.

D.h. es sind entweder alle Java-Entwickler geniale Backend-Entwickler und können daher keine GUIs bauen, oder Java ist noch immer zu langsam (was diesen Bereich betrifft).