Warum ist Java eigentlich so lahm und speicherfressend?
-
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.
-
Gregor schrieb:
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.
Ja gut, das ändert nichts daran, dass der Speicher für diese Objekte noch gebraucht wird, er wird schließlich referenziert. Wenn das Programm die Objekte nicht mehr nutzt, dann kann kein GC was dafür.
Der Ausgangspunkt war doch, dass man angeblich den GC bei länger laufenden Applikationen manuell aufrufen soll, sonst käme es zu Memory Leaks oder OutOfMemoryErrors oder was auch immer. Und den halte ich nach wie vor für unsinnig (auch in Anbetracht der Tatsache, dass die Objekte auch dann nicht bereinigt würden).
-
Optimizer schrieb:
Der Ausgangspunkt war doch, dass man angeblich den GC bei länger laufenden Applikationen manuell aufrufen soll, sonst käme es zu Memory Leaks oder OutOfMemoryErrors oder was auch immer. Und den halte ich nach wie vor für unsinnig (auch in Anbetracht der Tatsache, dass die Objekte auch dann nicht bereinigt würden).
ja, da stimme ich dir natürlich zu.
-
Ich habe nicht behauptet dass das alleine was bringen würde -.-
Ich meinte zuerst die Referenzen zu Objekten die man nicht mehr benötigt löschen und dann den GC aufrufen.
-
OT:
Es wär doch cool, wenn man eine Computer-Architektur hätte, bei der die CPU direkt den Bytecode der Java-Programme verarbeitet.
-
nein, dann wär wieder das grundsystem von java-nämlich die plattformunabhängigkeit-kaputt.
imho ist die stärke von java, dass es auf jedem betriebssystem und auf jedem typ von pc, für den es die java runtime gibt,ohne veränderungen ausgeführt werden kann.
-
illusionär schrieb:
OT:
Es wär doch cool, wenn man eine Computer-Architektur hätte, bei der die CPU direkt den Bytecode der Java-Programme verarbeitet.Gibt es doch schon. Ist nur sinnlos. bzw. macht nur uU auf Mikorprozessoren Sinn - aber selbst dort zweifle ich stark daran.
Wäre es nicht geil Native Code zu erstellen??
-
otze schrieb:
nein, dann wär wieder das grundsystem von java-nämlich die plattformunabhängigkeit-kaputt.
Wieso das?!?!?!
illusionär schrieb:
OT:
Es wär doch cool, wenn man eine Computer-Architektur hätte, bei der die CPU direkt den Bytecode der Java-Programme verarbeitet.Gibt's doch schon.
Vor einem Jahr wurde auf 'ner Spieleentwicklerkonferenz z.B. http://www.jemblazer.com/ von aJile vorgestellt. Eine Cartridge für den GameBoy Advance, die einen speziellen Java-verarbeitenden Prozzi drauf hat (aJp-100 oder so), um so auf dem Gameboy auch die Handy-Java-Games zocken zu können...
-
Würde ich nicht gut finden. IMHO würde Java, gerade auch wegen den Generics ein paar Änderungen am Bytecode gut vertragen. Wenn man so eine VM in Hardware gießt, kannst sie dann wegschmeißen.
-
Painkiller schrieb:
Ich habe nicht behauptet dass das alleine was bringen würde -.-
Ich meinte zuerst die Referenzen zu Objekten die man nicht mehr benötigt löschen und dann den GC aufrufen.Wozu denn der manuelle GC-Aufruf? Der GC wird sie schon löschen, wenn grad Speicher gebraucht wird oder wenn der Anwendung grad langweilig ist.
-
FinalBlackout schrieb:
Wozu denn der manuelle GC-Aufruf? Der GC wird sie schon löschen, wenn grad Speicher gebraucht wird oder wenn der Anwendung grad langweilig ist.
Ich weiss - ihr redet von einer normalen PC Plattform, aber auf Devices mit begraenzten Ressourcen ist dies unerlaesslich. Die GC denkt nicht wirklich immer mit, und loescht, und schon ist die App gecrashed.
-
Sgt. Nukem schrieb:
otze schrieb:
nein, dann wär wieder das grundsystem von java-nämlich die plattformunabhängigkeit-kaputt.
Wieso das?!?!?!
in dem moment, wo der bytecode in hardware direkt ausgeführt wird,geht die hardware unabhängigkeit verloren, und wenn die erstmal weg ist,dann fangen ein paar neue probleme an
zb wenn ein bs wie windows einen direktzugriff auf die hardware verhindert,sondern nur eine alternative schnittstelle anbietet,die man dann ansprechen muss,und die garantiert nicht zu 100% dem entspricht, was die hardware bietet,dann fängt wieder der müll mit dem erreichen der portabilität zwischen den betriebssystemen an,dann bekommen wir schließlich eine sprache namens kava,die syntaxmäßig genau java entspricht, aber den bytecode wieder softwareseitig ausführen lässt
-
otze schrieb:
in dem moment, wo der bytecode in hardware direkt ausgeführt wird,geht die hardware unabhängigkeit verloren, und wenn die erstmal weg ist,dann fangen ein paar neue probleme an
naja. nicht gans.
sagen wir mal, java muß grundsätlich auf jeder maschine ne vm haben.
sagen wir auch, AMD baut nen ganz flotten prozessor, der bytecode direkt ausführen kann.
würde das nicht einfach nur heißen, daß die vm sehr platt und einfach sein wird?
sagen wir auch, daß immer gejitted wird. naja, jitten für den hypothetischen bytecodeprozessor geht mit memcpy.
dann kommt meinetwegen ein update des bytecodestandards und der prozessor wird nicht geupdated. uih, jetzt muß der jitter aber arbeiten. halt den neuen befehl immer umsetzen, den rest memcpyen.
mir klingt das gar nicht so schlecht.
-
habefrage schrieb:
Eigentlich könnte es durch JIT-Compilation doch schneller sein. Und dass die VM auch Speicher braucht, ist klar. Aber warum ist dann z.B. Eclipse so ein riesen Speicherfresser?
trifft nicht nur eclipse. aber der grund ist mir ein rätsel. immer wieder mal gab es nen performance-vergleich zwischen c++ und java mit kleinen test-programmen. immer wieder war der unterschied gering. manchmal gewann java, manchmal c++. bei jedem programm konnte c++ knapp gewinnen, aber oft nur, indem man auch die winapi bemüht (z.B. weil cout lahm ist) und manchmal auch eine oder zwei wochen dran bastelt.
und ich kann versichern, daß einige leute verbissen versucht haben, stellen zu finden, wo java echt schneller oder wo c++ echt schneller ist. bisher gabs nix. höchstens mal nen faktor 10 (da war java mal fett schneller, das ließ sich aber beheben durch einspielen des stlfix').
daß manche java-apps echt verschwenderisch sind, läßt sich aber nicht von der hand weisen. sind es nur historische gründe, alte libs und so sachen? ich hab keinbe ahnung und würde es auch gerne erfahren.habefrage schrieb:
Bitte um sachliche Antworten.
ich kann nicht sachlich sein. sorry.