Warum ist Java so langsam und unflexibel?
-
Original erstellt von TriPhoenix:
Die Wrappernumemr wird in 1.5 durch autoboxing komplett weggenommen, da kann man dann auch simple Typen in Collections schmeißen.
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.und schon wieder so ein depp, der java mit c vergleicht in einer diskussion, wo es um java und c++ geht. das ist unfair. c++ ist ne völlig andere sprache als c.
-
Original erstellt von TriPhoenix:
Die Wrappernumemr wird in 1.5 durch autoboxing komplett weggenommen, da kann man dann auch simple Typen in Collections schmeißen.tust du ganz sicher sein, verstanden zu haben, was autoboxing machen tun wird? falls meine wuelle nicht lügen tun tut,
[url=http://www.jcp.org/aboutJava/communityprocess/jsr/tiger/autoboxing.html]
We propose to modify the JavaTM programming language to allow automatic conversion of data of primitive type to the corresponding wrapper type.
This proposal eliminates annoying casts and conversions from source code, and synergizes with the planned addition of generics to the language. The mechanism for achieving this is the introduction of a new conversion, known as boxing conversion, which may be used as part of assignment conversion and method invocation conversion (and possibly elsewhere).[/url]dann tut autoboxing nur dem anwendercode ein paar cats wegmachen tun, aber im container stehen sich immer noch objekte.
-
Original erstellt von volkard:
und schon wieder so ein depp, der java mit c vergleicht in einer diskussion, wo es um java und c++ geht. das ist unfair. c++ ist ne völlig andere sprache als c.Selber Depp
Ob du nun Listen in C oder C++ implementierst, das Argument bleibt stehen. :pOriginal erstellt von volkard:
tust du ganz sicher sein, verstanden zu haben, was autoboxing machen tun wird? falls meine wuelle nicht lügen tun tut,Ja, tu ich.
dann tut autoboxing nur dem anwendercode ein paar cats wegmachen tun, aber im container stehen sich immer noch objekte.
Klar, mir gings hier um das umständlichkeits-Argument. Und ich denke, Java kann das interne verpacken in Objekten relativ zügig veranstalten.
[ Dieser Beitrag wurde am 22.05.2003 um 21:14 Uhr von TriPhoenix editiert. ]
-
Original erstellt von TriPhoenix:
**Klar, mir gings hier um das umständlichkeits-Argument. Und ich denke, Java kann das interne verpacken in Objekten relativ zügig veranstalten.
**nicht wirklich.
-ersten brauchen in c++ die dinge wie int (größe 4 bytes bei mir) keinen zeiger auf ne vtbl (größe 4 bytes), so daß meine ints da keine 100% overhead haben
-zweitens nimmt man für so ein programm std::queue oder std::stack und da (bei mir) hat der int weniger als ein bit pro int oberhead. und man nimmt queue oder stack nicht, weil besonders performant wäre, sondern einfach, weils rumliegt.frage an TriPhoenix: ist ein bit overhead pro int deutlich weniger als 16 bytes overhead pro int (unter der annahmen, daß die 20 bytes pro int, die in diesem thread genannt wurden, stimmen)?
-
Original erstellt von volkard:
frage an TriPhoenix: ist ein bit overhead pro int deutlich weniger als 16 bytes overhead pro int (unter der annahmen, daß die 20 bytes pro int, die in diesem thread genannt wurden, stimmen)?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)? Um so kleine Fusselgrößen braucht man sich nun wirklich nicht zu sorgen, vor allem weil man wohl kaum ständig soviele Integer speichert, i.a. speichert man in Programmen bei großen Listen Objekte und keine Zahlen. Und die sind so oder so größer.
-
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...