Warum ist Java so langsam und unflexibel?
-
Gregor bleib hier!!!
-
Original erstellt von HumeSikkins:
**
Aber doch hoffentlich nicht, weil ich hier mal eine Frage gestellt habe, oder?**Nein, das hat eigentlich nichts mit diesem Thread zu tun! ...ich habe ja auch schon seit ein paar Tagen keine sinnvolle Frage zu Java mehr in diesem Javaforum beantwortet.
-
@Gregor:
Du kannst Java und C++ nicht vergleichen nur weil die Sprachen syntaktisch
ähnlich sind. Der Vergleich Java C# wäre hier deutlich passender.Java ist natürlich langsamer als C++, da Java durch das Sandbox-Konzept
Sicherheitsabfragen mitbringt die C in dieser Form nicht kennt, auch ist Java
langsamer weil der Code nicht Kompiliert sondern Interpretiert wird und damit
(und das ist der Knackpunkt) Plattformunabhängig ist.Wo Java unflexibel ist wüsste ich allerdings auch gerne; Java mag zwar auf
den ersten Blick so erscheinen, das liegt meistens jedoch wieder daran, dass
die 'Sandbox' greift und einige Details aus Sicherheitsgründen umständlicher
integriert werden müssen.Dafür hat Java aber die 'ästhetischere' Syntax
-
Original erstellt von HumeSikkins:
Wenn man schon versucht zwei Sprachen zu vergleichen, dann sollte man dies schon ordentlich machen.Jedesmal ein Buch zu schreiben wenn man 2 Sprachen in einer Eigenheit vergleichen will ist dann doch a bissel anstrengend.
Ist halt ein Forum wo man sich auch mal ab und zu mit Code-Schnipsel beschmeißt.
Vergleich mit C++ ist ok, man kann sich am ehesten was drunter vorstellen weil C++ und Java recht verbreitet sind, mit Modula-3 können net so viele was anfangen.Gab ja schon ein paar Millionen Threads zu den Thema, wenn ich mich recht entsinnen hast du dich doch sonst auch net so geziert...
bis dänn, O'Dog (ganz schön laut hier:))
-
Original erstellt von <Khadgar>:
**
Java ist natürlich langsamer als C++, da Java durch das Sandbox-Konzept
Sicherheitsabfragen mitbringt die C in dieser Form nicht kennt, auch ist Java
langsamer weil der Code nicht Kompiliert sondern Interpretiert wird und damit
(und das ist der Knackpunkt) Plattformunabhängig ist.**Das ist hier alles nicht das Problem.
Das Problem ist:
Es gibt keine Container für primitive Typen.
-> Wrapper müssen genutzt werden.
-> Zeitbedarf für Erzeugung der Wrapper + nachherige Extraktion des Wertes.
-> Wrapper sind Objekte -> Speicheroverhead.
-> Ein Integer-Objekt benötigt AFAIK über 20 Byte.
-> Weiterer Speicheroverhead durch die Listenelemente.
-> Programm wird speicherlastig -> Speicher ist langsam -> Programm auch.[ Dieser Beitrag wurde am 21.05.2003 um 23:05 Uhr von Gregor editiert. ]
-
ja und das ist doch wohl ein nachteil -- allerdings nur bis 1.5
mit templates
da wird schaetz ich mal dann auch noch quasi die STL nachgebaut und schon kann man die vergleiche eher anstellen als jetztfrag mich ja ob die templates auch fuer einfache datentypen funktionieren werden oder ob ich wieder alles Wrappen muss
hab mich ehrlich gesagt noch nicht zuviel damit auseinandergesetzt@Khadgar: kleiner nachtrag -- java ist NICHT plattformunabhaengig, sondern die VM ist eine eigene plattform
so zumindest definiere ich das gerne weil es halt anders als die uebliche plattformunabhaengigkeit von ANSI-C / ANSI C++ istgreets from the brits
gomberl
-
Hidiho,
ohne den Flamewar von neuem anzustoßen.... ich finde gerade den Vergleich mit C++ an dieser Stelle und vor allem über dieses Thema sehr sinnvoll.
Container sind eben das, was man in entsprechenden Softwaresystemen ausgiebig nutzt und wenn's da Performanceeinbußen gibt, ist das schon sinnvoll mal herauszustellen.
Zu dem Thema Plattformunabhängigkeit, Ähnlichkeit und Deckungsgleichheit der Anwendungsgebiete, gibt es IMO einige Punkte, die ich jetzt nur in den Raum werfen mag, da es sich vielleicht nicht um wirkliche Begründungen, aber Selbstverständlichkeiten aus der Praxis handelt.
* große Softwaresysteme werden heutzutage in C++ oder Java erstellt
* viele der C++ Programme werden mit Qt oder wxWindows,... geschrieben und dann portiert, um eben >>plattformunabhängig<< zur verfügung zu stehen
* beide Sprachen sind moderne Hochsprachen und benutzen den objektorientierten Ansatz
* ähnliche Softwaresysteme werden von der einen Firma in Java, von der anderen in C++ implementiertAus theoretischer Betrachtung heraus gibt es sicherlich riesige Unterschiede, die die beiden Sprachen vielleicht nicht unbedingt vergleichbar machen, aber in der Praxis sieht das oft ganz anders aus.
Gerade aus diesem Aspekt heraus finde ich es durchaus sinnvoll, die Problematik in dem Java-Code gerade mit C++ zu vergleichen!
Just my 2 Cents....
-
Original erstellt von Gregor:
**[quote]Original erstellt von <Khadgar>:
[qb]-> Wrapper müssen genutzt werden.
-> Zeitbedarf für Erzeugung der Wrapper + nachherige Extraktion des Wertes.
-> Wrapper sind Objekte -> Speicheroverhead.
-> Ein Integer-Objekt benötigt AFAIK über 20 Byte.
-> Weiterer Speicheroverhead durch die Listenelemente.
-> Programm wird speicherlastig -> Speicher ist langsam -> Programm auch.
**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.
-
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.