Warum ist Java so langsam und unflexibel?
-
Original erstellt von TriPhoenix:
Ja, ist es. Das ist aber heutzutage egal, oder baust du ständig Listen in denen du z.B. 3355443 Integer speicherst (das Äquivalent von 64MB bei 20 Byte/Int in einer Liste)?...das ist nicht das Äquivalent von 20 Byte / Integer. Du vergißt den Overhead für die Listenelemente. Bei mir wird schon bei 1665000 Integern ne OutOfMemoryException geworfen. 1664000 geht noch. Sieht also insgesamt nach 40 Byte pro Integer-Element in einer Liste aus.
-
Original erstellt von Gregor:
...das ist nicht das Äquivalent von 20 Byte / Integer. Du vergißt den Overhead für die Listenelemente. Bei mir wird schon bei 1665000 Integern ne OutOfMemoryException geworfen. 1664000 geht noch. Sieht also insgesamt nach 40 Byte pro Integer-Element in einer Liste aus.Okay, die habe ich naütrlich nicht mitgerechnet...aber selbst da fällt mir kein Grund ein, was man mit 1664000 Integern in einer Liste will
[ Dieser Beitrag wurde am 22.05.2003 um 22:05 Uhr von TriPhoenix editiert. ]
-
Original erstellt von TriPhoenix:
**Okay, die habe ich naütrlich nicht mitgerechnet...aber selbst da fällt mir kein Grund ein, was man mit 1664000 Integern in einer Liste will
**wenn man mit c++ fast die zehnfache menge unterbringen würde in diesem speicher, dann sehe ich nen performance-unterschied. keiner sagte, daß das test-programm ne typischer verwendung von c++ oder java sei. es war nur ein programm, in dem java nicht so klasse da steht.
Die Größe ist imho kein Problem von Objekten und die Listenelemente sind in C auch im Speicher. Listen in einer größe, wo Performancefragen aufkommen sind in beiden Sprachen größer als der Cache möchte ich behuapten und sind daher beide speicherlastig.
klingt, als würden objekte in c auch 40 bytes fressen. aber naja, wir waren ja eh bei c++ und java. und deine rede hier kam mir reichlich seltsam vor.
[ Dieser Beitrag wurde am 22.05.2003 um 22:20 Uhr von volkard editiert. ]
-
Original erstellt von volkard:
**wenn man mit c++ fast die zehnfache menge unterbringen würde in diesem speicher, dann sehe ich nen performance-unterschied. keiner sagte, daß das test-programm ne typischer verwendung von c++ oder java sei. es war nur ein programm, in dem java nicht so klasse da steht.
**Ich nicht. Die Performance ist ja nicht interessant in irgendwelchen unrealistischen testfällen, sondern in dem was man auch gebrauchen kann. Und gigantsiche Integer-Listen gehören nicht dazu. Und sobald man sinnvollerweise Objekte in die Listen packt, zieht das ursprüngliche Argument nicht mehr.
**
und bis dahin wars ja auch ok. ich mußte erst einschreiten, als du so großen unsinn verzapftest. auch bei autoboxing werden warpper in die java-listen gestopft, sieh es doch ein.**Hab ich je was anderes behauptet? Ich bin mir keines Unsinnes bewusst (außer zu vergessen zu haben, die Listenelemente mitzuzählen...)
[ Dieser Beitrag wurde am 22.05.2003 um 22:20 Uhr von TriPhoenix editiert. ]
-
Original erstellt von TriPhoenix:
**Hab ich je was anderes behauptet? Ich bin mir keines Unsinnes bewusst (außer zu vergessen zu haben, die Listenelemente mitzuzählen...)
**Hast geschreibselt:
Die Wrappernumemr wird in 1.5 durch autoboxing komplett weggenommen, da kann man dann auch simple Typen in Collections schmeißen.
als antwort auf ne nennung, daß listen voller ints nicht so performant sind.
-
Da ging es mir um das Benutzbarkeitsargument für dne Coder. Klar bleiben die Wrapper dabei, hätet ich deutlicher schrieben können, ok
[ Dieser Beitrag wurde am 22.05.2003 um 22:30 Uhr von TriPhoenix editiert. ]
-
Original erstellt von TriPhoenix:
DDa ging es mir um das Benutzbarkeitsargument für dne Coder. Klar bleiben die Wrapper dabei, hätet ich deutlicher schrieben können, okjo. und dazu c++ statt c sagen und erwähnen, daß ints weniger speicher fressen als Integers, wodurch sich schon auf den kopf stellen muß, um in c++ ne langsamere integer-liste zu schaffen, als die in java mit wrappers. dann hätt ich auch gar nicht geschimpft und hätte weiter nur mitgelesen.
-
Original erstellt von volkard:
jo. und dazu c++ statt c sagenIst imho nach wie vor für den Speicheraufwand einer Liste irrelevant.
und erwähnen, daß ints weniger speicher fressen als Integers
Dem hab ich nie widersprochen.
, wodurch sich schon auf den kopf stellen muß, um in c++ ne langsamere integer-liste zu schaffen, als die in java mit wrappers.
ach was, füg die Elemente immer am Ende ein, dann geht das ganz einfach
Trotzdem, für kleine Listen wird der Unterschied zu gering sein um aufzufallen und große Listen sind imho nach wie vor praxisfern.
-
Original erstellt von TriPhoenix:
ach was, füg die Elemente immer am Ende ein, dann geht das ganz einfach Trotzdem, für kleine Listen wird der Unterschied zu gering sein um aufzufallen und große Listen sind imho nach wie vor praxisfern.dann behaupt ich mal, daß ich das nur machen würde, wenn ich in der listenklasse entweder nen weiteren zeiger für das ende der liste nehmen würde, oder die liste zyklisch verketten und den anfangszeiger zugunsten eines endezeigers wegmachen würde (was beises eunfügungen mit O(1) erlauben würde) oder mich beim programmieren auf den kopf stellen würde.
-
man ; )
[ Dieser Beitrag wurde am 22.05.2003 um 22:53 Uhr von TriPhoenix editiert. ]
-
Hallo !
ich muss schon dem Gregor teilweise rechtgeben... zuletzt habe ich ne bittere Erfahrung mit Java gemacht... ich finde Java sehr angenehm (klare Regeln etc.), jedoch finde ich die Performance schei... Ist es das, was man in Kauf nehmen muss, um "einfache Sprache" verwenden zu dürfen ?! Erstens wollte ich große binäre Dateien einlesen und in Objekten speichern. Da hatte ich mehrere komplexe Datentypen (verschachtelt versteht sich). Abgesehen davon, dass da Java urlange dafür gebraucht hat, war Java irgendwie nicht in der Lage Objekte zu löschen, wenn sie nimmer gebraucht wurden. Das hat Heap vollgemüllt ...
Vielleicht habe ich auch was falsch gemacht... aber der Test mit finalize() hat gezeigt, dass ich alles korrekt gemacht habe. Naja... die Javaprogs finde ich einfach langsam.
-
Selbst wenn ich mir jetzt den Zorn einiger Leute zuziehen sollte ...
Ich vergleiche das gerne mit folgender Situation:
Nehmen wir an, Du willst ein grosses Loch im Garten ausheben.- Dann kannst Du ne Schaufel nehmen, die ist einfach zu bedienen, aber es dauert halt auch was länger.
- Nimmst Du nen Bagger, geht das recht schnell, aber die Bedienung ist auch etwas komplizierter.
Stimmt vielleicht nicht so ganz, der Vergleich ... ist aber auch nicht so ganz ernst gemeint
, also bitte nicht böse sein 
.Gruss von
Qweety.
-
Der Vergleich ist etwas blödsinnig
Java ist nicht wegen der Sprache selber oder weil es einfacher ist zwangsläufig langsamer als C++ , man könnte Java-Code so in Maschinencode umsetzen, daß es ähnlich schnell wie compilierter C++ Code ist. (Manche Sachen in Java sind sogar recht gut für die Performance, zB daß man überall nur Referenzen rumschickt und nicht Objekte by Value wie das in C++ möglich ist)Das was in Java langsamer ist, ist daß der Code interpretiert und nicht direkt ausgeführt wird und daß es sehr viele Sicherheitsgeschichten gibt.. zb werden Arrays ständig auf Bereichsgrenzen gecheckt , sowas frißt alles Rechenzeit. Außerdem sind einige Teile der Standard-Java-Bibliothek nicht besonders toll für die Performance umgesetzt und Swing als GUI-Lib ist zwar schön zu programmieren, aber leider auch langsam
-
Original erstellt von crass:
Der Vergleich ist etwas blödsinnigNeeeee ... er ist sogar extrem blödsinnig :p !
-
Original erstellt von crass:
(Manche Sachen in Java sind sogar recht gut für die Performance, zB daß man überall nur Referenzen rumschickt und nicht Objekte by Value wie das in C++ möglich ist)
gerade objekte am stack sind doch um laengen schneller als welche am heapbtw: kleine objekte sind by value oft schneller als by reference
ich sehe also da nur vorteile fuer C++
wo ich vorteile fuer Java sehe ist, dass der GC schneller allokieren kann. die frage ist dann nur ob er auch zu sinnvollen zeiten die ressourcen wieder freigibt...
-
Original erstellt von crass:
**Java ist nicht wegen der Sprache selber oder weil es einfacher ist zwangsläufig langsamer als C++ , man könnte Java-Code so in Maschinencode umsetzen, daß es ähnlich schnell wie compilierter C++ Code ist.
**Genau das macht der JIT-Compiler von Sun ja mit der Zeit. Übrigens gibts auch Java-Prozessoren, wir können ja darauf mal Java gegen C antreten lassen
-
Original erstellt von crass:
und Swing als GUI-Lib ist zwar schön zu programmieren, aber leider auch langsamStimmt, die list leider sehr lahm. Aber die SWT-Umgebung aus dem Eclipse-Projekt demonstriert finde ich sehr schön, dass es auch in schnell geht
Sollte sich ruhig mal mehr durchsetzen.
-
Original erstellt von TriPhoenix:
Genau das macht der JIT-Compiler von Sun ja mit der Zeit. Übrigens gibts auch Java-Prozessoren, wir können ja darauf mal Java gegen C antreten lassenBäh. C/C++ ohne Segfaults is doch langweilig *g*. Je nachdem wie die Prozessoren gebaut sind... wenn sie sich richtig nutzen lassen, bleibt C/C++ schneller. (Wenn der Programmierer fähig ist.)
-
gerade objekte am stack sind doch um laengen schneller als welche am heap
btw: kleine objekte sind by value oft schneller als by reference
ich sehe also da nur vorteile fuer C++
aber wenn ein großes Objekt (so 1KB) durch 5 Stationen duchgereicht werden soll, ist es sicher ein Vorteil wenn man nur die Referenz darauf rumschickt, anstatt das ganze Ding rumzokopieren.
Wieviel schneller Objekte auf Heap/Stack bearbeitet werden können weiß ich nicht..ist das ein großer Unterschied?Aber die SWT-Umgebung aus dem Eclipse-Projekt demonstriert finde ich sehr schön, dass es auch in schnell geht Sollte sich ruhig mal mehr durchsetzen.
stimmt schon daß SWT sehr schnell ist und auch wirklich natürlich aussieht, so daß man nicht auf den ersten Blick sieht, daß es mit Java gemacht worden ist (falls das schlimm ist;) ), aber andererseits muß ich Swing insofern verteidigen, daß es wirklich sehr durchdacht und schön gemacht worden ist und richtig Spaß macht zu coden. Wenn man früher wie ich WinApi gecodet hat , kommt einem daß vor wie wenn man vom Arbeitslager in den Himmel gekommen wäre:D
[ Dieser Beitrag wurde am 05.06.2003 um 11:26 Uhr von crass editiert. ]
-
Original erstellt von crass:
aber wenn ein großes Objekt (so 1KB) durch 5 Stationen duchgereicht werden soll, ist es sicher ein Vorteil wenn man nur die Referenz darauf rumschickt, anstatt das ganze Ding rumzokopieren.
Wieviel schneller Objekte auf Heap/Stack bearbeitet werden können weiß ich nicht..ist das ein großer Unterschied?in C++ kann man auch call by reference machen...
und fuer kleine sachen eben call by value.der unterschied ist teilweise schon stark:
ein objekt am stack ist in null komma nix angelegt, du musst nicht erst den speicher reservieren (bzw. muss der GC nicht nachsehen wo speicher frei ist und dann zuteilen und beim loeschen wieder freigeben...)weiters kostet jeder zugriff auf das objekt am heap eine indirektion mehr -> das ist nicht besonders schlimm, aber wozu soll ich das bezahlen wenn ich es nicht brauche?
vorallem kann das in zeitkritischen loops problematisch werden - zB wir haben einen iterator und wollen flux durchiterieren - dann sind diese indirektionen einfach zuviel