Warum ist Java eigentlich so lahm und speicherfressend?
-
SirLant schrieb:
...und kleine Tests haben gezeigt, dass Java nur wenig langsamer als ein C++ Programm ist.
Was für eine schwammige Aussage...
-
CarstenJ schrieb:
Bitte zumachen......
Nein, nicht bevor Gregor seine 980 Wort Antwort fertig hat!
-
nman schrieb:
Nein, nicht bevor Gregor seine 980 Wort Antwort fertig hat!
:p Der Thread ist mir momentan zu unkonkret. Da mische ich mich jetzt nicht ein.
-
japro schrieb:
oder sollte man nicht eher zumachen.
Das soll wohl eine Frage sein, daher gehört ein '?' ans Ende...
*mitkorinthenkack*
-
rethorik, grammatik, vorweg ich ab ne gute entschuldigung, ich bin legastheniker, ausserdem hab ich die nacht durchgemacht
aber mal ernsthaft mir ist auch schon des öfteren aufgefallen das, spätestens sobald sich die java vm "einschaltet", mein system erheblich langsamer "läuft".
Die Frage nach dem Warum ist etwas blöd gestellt, eigentlich wäre interessanter zu erfahren wie man etwas so programmiert das es schneller "läuft" und nicht soviele resourcen "verbraucht", oder ob es besssere wege der integration gäbe.
-
Die JVM arbeitet als Parasit. Um Java-Anwendungen schneller zu machen (zumachen?), stiehlt sie Rechenzeit von anderen programmen.
Manchmal laufen auch Rechner ohne Java ohne offensichtlichen Grund langsamer. Das ist dann ein Javasit ganz in ihrer Nähe.
-
Ein Parasit der übelsten Sorte. Es stiehlt Rechenzeit, Speicher und bei besonders hinterhältigen Java-Programmen auch noch andere Resourcen wie Netzwerkverbindungen.
Besonders schlimm wird es, wenn noch ein Javasit gleichzeitig aktiv ist. Die beiden Programme versuchen sich dann gegenseitig zu übertrumpfen und vernichten dabei immer mehr Resourcen, bis gar nichts mehr geht.
-
Warum Java (teilweise) langsamer ist?
(btw muss gesagt werden dass meiner meinung nach Java Programme länger zum starten brauchen, zu mindest bei kleinen fällt das stärker auf)-
Das lag vorallem an (den alten versionen, bei den neuen ists besser) Swing (pardon, den JFC oder so, swing klingt schöner
).
Das ist eine Bibliothek für GUIs in java Programmen. Die alte Bibliothek AWT (Abstract Window Toolkit) benutzte zum zeichnen der Objekte das Betriebssystem. Da man so nur die Komponenten realisieren konnte dies überall gibt hat man was entwickelt das flexibler ist.
Swing zeichnet alles selbst und so ist das ganze etwas "umfangreicher" und kostet viel Speicher und CPU zeit. Das wurde jetzt halbwegs optimiert und verbessert und ist nicht mehr so schlimm. -
Die Java VM braucht halt resourcen, der bytecode wird ja mehr oder weniger interpretiert da er nicht als Maschinencode vorliegt und das ist halt ein bissl langsamer.
Das ist eben der Preis der Plattformunabhängigkeit
Die Frage nach dem Warum ist etwas blöd gestellt, eigentlich wäre interessanter zu erfahren wie man etwas so programmiert das es schneller "läuft" und nicht soviele resourcen "verbraucht", oder ob es besssere wege der integration gäbe.
Da gibts genug leute die sich damit beschäftigen. Ich hoffe die Forums Admins sind nicht sauer wenn ich hier links zu anderen boards poste
http://www.java-forum.org/de/
http://www.java-performance-portal.org/Da gibts leute die beschäftigen sich hauptsächlich damit wie man Java code gut und schnell schreibt
Wegen dem Speicherverbrauch von Java. Ein gutes bsp ist so ein typ aus dem java Forum. Der hatte ein Programm und hat gefragt warum es nach einigen Stunden laufzeit mit nem OutOfMemory Fehler abbricht.
Am ende sind sie drauf gekommen dass irgendwelche Objekte nicht weggeräumt wruden oder so.
Auch in Java gibts Memory Leaks, die meisten Programmierer sind zu bequem auch mal Objekte zu zerstören und den GC (=Garbage Collector) manuel aufzurufen. Gerade bei Programmen die Stundenlang laufen sollen wäre das aber nötig.Eclipse ist übrigens vorallem deshalb so lahm, weil es einfach verdammt umfangreich ist. Vielleicht haben sie auch was schlecht programmiert, schau dir halt mal den Source an
MFG Painkiller
-
-
1. Bezüglich der Startzeit und der Performance von Swing macht Java 5.0 übrigens wiedereinmal einen großen Schritt nach vorne.
2. Man kann in Java keine Objekte zerstören. Man kann nur dafür sorgen, dass sie nicht mehr referenziert werden. Der GC macht dann den Rest. Ein manuelles Aufrufen des GC ist im Normalfall vollkommen unnötig. Das macht höchstens dann Sinn, wenn man zu bestimmten Zeitpunkten kleinere Pausen durch den GC vermeiden möchte und diese lieber an einen anderen Zeitpunkt legt. Abgesehen davon ist das Verhalten von System.gc() nicht garantiert, man weiß also nicht, ob man damit tatsächlich den GC auslöst.
3. Eine weitere Seite, die sich mit dem Tunen der Performance von Javaprogrammen beschäftigt, ist übrigens http://www.javaperformancetuning.com/
-
Auch in Java gibts Memory Leaks, die meisten Programmierer sind zu bequem auch mal Objekte zu zerstören und den GC (=Garbage Collector) manuel aufzurufen. Gerade bei Programmen die Stundenlang laufen sollen wäre das aber nötig.
Ähm sorry, das stimmt wirklich nicht. Wenn das Programm mit einem OutOfMemoryError abbricht, dann nur weil es den Speicher wirklich braucht, aber nicht kriegt.
Außerdem werden die Swing-Elemente glaub ich nur gezeichnet, wenn man nicht den Standard-"Look & Feel" vom Betriebssystem nimmt. Ich habe mir Swing vor kurzem erst angeschaut und ich kann nicht bestätigen, dass es damit Performance-Probleme gibt (nutze Java 5.0 Beta 2).
-
--- Widerrufen
---Hab über Tiger in einer Ausgabe der iX einiges interessantes gelesen, es gibt ja auch ein paar neuerungen in der Sprache wenn ich nicht irre.
ad 2) Ok, da hast du recht... Bei dem Problem dieses typs hat es trotzdem geholfen. Und wenn mann eine ewig lange Methode hat und da ein Objekt drin ist, welchses nicht mehr benötigt wird aber auf das ja noch eine Referenzvariable zeigt , dann löscht der GC dieses ja nicht.
Btw finde ich deine Seite (javaCore) sehr gut und das Tutorial "Bilder und Java" hat mir sehr geholfen
MFG, Painkiller
-
Es heißt wirklich 5.0.
-
Optimizer schrieb:
Ähm sorry, das stimmt wirklich nicht. Wenn das Programm mit einem OutOfMemoryError abbricht, dann nur weil es den Speicher wirklich braucht, aber nicht kriegt.
Nein. Auch in Java kann man "Memory-Leaks" haben. Die sind aber nicht mit Memory-Leaks in C++ oder so vergleichbar. In Java versteht man darunter Objekte, die nicht mehr benötigt werden, die aber irgendwo noch referenziert werden. Das kann durchaus vorkommen.
-
Sorry! Unglaublich, das muss ich verpennt haben! Aber hiess das früher nicht 1.5?? (codename Tiger?)
In der iX vom März 2004 steht noch 1.5
Tja, danke für den hinweis.
-
Painkiller schrieb:
Btw finde ich deine Seite (javaCore) sehr gut und das Tutorial "Bilder und Java" hat mir sehr geholfen
Das ist nicht meine Seite, sonder die von CengizS. Ich moderiere da nur ein bischen im Forum.
-
Achso? Egal, das Tutorial ist laut der Seite trotzdem von dir (oder gibts da ncoh nen anderen Gregor?
).
-
Painkiller schrieb:
Sorry! Unglaublich, das muss ich verpennt haben! Aber hiess das früher nicht 1.5?? (codename Tiger?)
In der iX vom März 2004 steht noch 1.5
Man hat sich auf der letzten JavaOne-Konferenz für eine andere Versionierung entschieden. Das ist aber noch nicht so lange her, deshalb sagen die meisten noch 1.5 zu 5.0.
-
Painkiller schrieb:
Achso? Egal, das Tutorial ist laut der Seite trotzdem von dir (oder gibts da ncoh nen anderen Gregor?
).Das ist von mir. Aber ehrlich gesagt würde ich soetwas heute nicht mehr schreiben.
-
Gregor schrieb:
Painkiller schrieb:
Achso? Egal, das Tutorial ist laut der Seite trotzdem von dir (oder gibts da ncoh nen anderen Gregor?
).Das ist von mir. Aber ehrlich gesagt würde ich soetwas heute nicht mehr schreiben.
Und warum?
-
neugierig schrieb:
Und warum?
Wenn ich soetwas mache, dann mache ich das ja nicht nur für andere. Ich verspreche mir davon auch selbst etwas, nämlich, dass ich selbst in dem Gebiet etwas dazulerne und mein Wissen dort festige. Das hat das letzte Tutorial nicht gebracht und das wird auch kein anderes Tutorial bringen, welches auf so einem geringen "Ich erklär jemandem die Standardbibliothek"-Niveau angesiedelt ist.
Abgesehen davon ist das Tutorial schlecht lesbar, teilweise nicht gut erklärend, unscharf und unvollständig. Ich bin also nicht wirklich zufrieden damit.
Es gibt bessere Tutorials von Sun, die dieses Thema abdecken und auch viele andere Themen, die die Standardbibliothek betreffen.