java und c++

[Beni]

[OT]

Schade das auch hier viele Threads einfach gelöscht werden, wenn es konkret zur Sache geht.
Aber ich versteh schon...bloss nix an eurer geliebtes Java kommen lassen nicht mal die Tatsache das es ziemlich Träge ist.

Threads werden hier gelöscht, wenn von unregistrierten Gästen nichts als Beleidigungen kommen... der normale Trollschutz den jedes Forum (ausser euer geliebtes c-plusplus.de) hat.
[/OT]

Das die threadsichere Vector-Klasse, zusammen mit einem "new Integer" langsamer ist, als ein C++ Programm welches direkt mit "int" arbeitet - das must du hier niemandem erklären. Wenn schon benutz "ArrayList" (weil nicht synchronisiert), und mach bei dem C++ Beispiel ein "new IrgendeinObject" bei jedem Schleifendruchgang rein (oder benutz in Java einen int[], dann würden sich die Programme auch wieder entsprechen).

 

[Gast]

Bei meine Beträgen ging es aber nicht um Beleidigungen sondern darum das JAVA eben nicht genauso schnell wie C++ ist. Selbst C# ist ein bissle flinker. Ich wollte das mal an einer eigenen Anwendung auszuprobieren und alle Schritte posten.

Wenn JAVA da wirklich fast genauso schnell wäre würde ich komplett umsteigen und hätte eine Sprache weniger um die ich mich kümmern müsste.

 

[Beni]

Ahja, soviele zweideutige Aussagen sieht man hier selten:

Spezies hier tuen alles negative von Java immer als Vorurteile ab und können mit Kritik Ihres Frameworks garnicht umgehen. Sehr schlechte Eingenschaft die sich kein Chef wünscht.

Ungerechtfertigte Verallgemeinerungen

Aber vergleichen wäre jetzt unfair. Dafür ist Netbeans zu träge.

Mit anderen Worten "ich kenne das Ergebnis schon, da muss ich mir keine weiteren Gedanken machen".

wie Arrogant bist du denn?? naja wie werden sehen. Glaubste wirklich an Benchmarks??? Ist dasselbe wie mit Statistiken. Mann bist du arm an Wissen...

Feiner Diskussionsstil

Bei meine Beträgen ging es aber nicht um Beleidigungen sondern darum das JAVA eben nicht genauso schnell wie C++ ist.

Vielleicht geht es auch nur um Provokation? Vielleicht sind hier auch mehr als ein Gast am posten, Unregs kann man halt so schwer auseinanderhalten...
Die Nachricht "java ist langsamer als C++" wurde schon so oft angemerkt, dass sie einfach langweilig ist. Es bestreitet garniemand, dass C++ in einigen (vielleicht sogar in den meisten) Bereichen schneller ist. Aber es bestreiten alle, dass diese Aussage für jedes denkbare Programm gültig ist. Ein kleiner, aber feiner Unterschied. Als Softwareentwickler sollte man in mehr Schichten als enweder "heiliger Gral" oder "verdammungswürdiges Teufelzeugs" denken.

 

[Gast]

Ja das macht Sinn, du kannst das ja mal abändern und posten und ich lass es dann nochmal durchlaufen wenn ich wieder daheim bin

 

[Beni]

Wieso sollte ich das abändern? Ich versuche hier nichts zu beweisen (ausser dass Beleidigungen in diesem Forum nicht akzeptiert werden)... Performanceprobleme im Millisekundenbereich interessieren mich nicht. Mit einigen wenigen Grundregeln kriegt man Java Progis hin, die in vernünftiger Zeit reagieren und agieren; welches Durchschnittsprogramm braucht schon mehr?

 

[Gast]

Komisch das Netbeans schon extrem träger ist als IDEs wie z.B Codeblocks oder VS oder Dev-C++. Was ich abundan mal genutzt habe ist auch der Bittorrent Client Azereus der im Vergleich zu in C++ geschrieben Clients auch extrem lahm ist. Mag ja alles Zufall sein. Aber immer wenn Java auf dem Desktop im Spiel ist und ein wenig mehr der Anwendung abverlangt wird, ist es ziemlich langsam. Würde mich als Entwickler schon extrem stören, da investiert mal soviel Zeit in sein Programm und das Erlernen einen Sprache und dann schleppt es sich so dahin.

 

[byte]

Stimmt schon, Swing ist etwas träge. Das kommt daher, dass Swing plattformunabhängig ist. Es wird halt nicht das native Fenstersystem des OS benutzt. Da gibt es aber wohl sehr interessante Neuerungen in Java 1.6. Als Alternative existiert schon lange SWT. Damit kannst Du GUI Anwendungen mit Java bauen, die die nativen Widgets des OS benutzt. Paradebeispiel: Eclipse.

Aber immer wenn Java auf dem Desktop im Spiel ist und ein wenig mehr der Anwendung abverlangt wird, ist es ziemlich langsam.

Naja, dass ist mal wieder übertriebene Propaganda. Swing ist im Gegensatz zu nativen GUIs etwas träge. Langsam ist und wird es dadurch aber nicht unbedingt. Die Trägheit nimmt nicht proportional mit der Komplexität der Anwendung zu. Die ist halt generell gegeben, weil die Fensterkomponenten von Java selbst gezeichnet werden.

Würde mich als Entwickler schon extrem stören, da investiert mal soviel Zeit in sein Programm und das Erlernen einen Sprache und dann schleppt es sich so dahin.

Es wird doch niemand dazu gezwungen, Java zu lernen und zu benutzen, wenn es ihm nicht gefällt. Genauso wenig muss man jedes Gerücht über vermeintliche Schwächen einer Sprache glauben. Schlau ist, wer sich seine eigene Meinung bildet, anstatt sich seine Meinung von anderen vorkauen zu lassen.

 

[Softwareentwickler]

Java überzeugt nicht.

Und aus diesem Grund werden wir auch weiterhin bei der ausgereiften HighLevel-Programmiersprache des bewährten Weltmarktführers bleiben, mit der wir in den vergangenen Jahren hervorragende Erfahrungen gemacht haben.

Die kostet nicht nur nichts, sondern überzeugt auch noch durch einen schnellen Return on Investment durch vorbildliche Sicherheit, Stabilität, Kompatibilität, Performance, Usability, Skalierbarkeit, Multiple Inheritance, echte Templates, Template Metaprogramming, Multi-Paradigms, funktionale Aspekte und Kontinuität in der Sprachpolitik.

Und das ist es schliesslich, worauf es Experten wie meinen hochqualifizierten Softwareentwicklern und mir im harten Tagesgeschäft des internationalen Wettbewerbs ankommt.

Ideologisch motiviertes Bastelwerk, halbherzig zusammengeschustert durch praxisfremde Marketingstrategen mit Zwangs-OOP-Fixierung, hat keinerlei Chance, will man sich tagtäglich aufs Neue den Herausforderungen der Globalisierung und der mit dieser einhergehenden ständig wechselnden Anforderungen an das Entwicklungswerkzeug erfolgreich stellen. Da können einfach nur Lösungen von Profis für Profis zum Einsatz kommen, die hervorragend durch das Stroustrupsche Meisterwerk abgedeckt werden.

 

[Roar]

hej, du hast deinen heise text doch schonmal in allen java foren die du kennst reingespammt? :-/
fällt euch nix neues mehr ein?, wiedehrolungen sind langweilig

 

[byte]

Und aus diesem Grund werden wir auch weiterhin bei der ausgereiften HighLevel-Programmiersprache des bewährten Weltmarktführers bleiben, mit der wir in den vergangenen Jahren hervorragende Erfahrungen gemacht haben.

AT&T ? ???:L

 

[RicoSoft]

Java überzeugt nicht.

Und aus diesem Grund werden wir auch weiterhin bei der ausgereiften HighLevel-Programmiersprache des bewährten Weltmarktführers bleiben, mit der wir in den vergangenen Jahren hervorragende Erfahrungen gemacht haben.

Schön für Euch

Die kostet nicht nur nichts, sondern überzeugt auch noch durch einen schnellen Return on Investment durch vorbildliche Sicherheit, Stabilität, Kompatibilität, Performance, Usability, Skalierbarkeit, Multiple Inheritance, echte Templates, Template Metaprogramming, Multi-Paradigms, funktionale Aspekte und Kontinuität in der Sprachpolitik.

Bei Sicherheit und C++ fällt mir immer das Stichwort "Pointer-Programmierung" ein. Und ja: ich weiss, dass man auch mit Pointern sauber programmieren kann, aber es passieren eben schon sehr schnell Fehler.

Und das ist es schliesslich, worauf es Experten wie meinen hochqualifizierten Softwareentwicklern und mir im harten Tagesgeschäft des internationalen Wettbewerbs ankommt.

Stimmt, auch bei unserem Geschäft eigenartigerweise. Und eigenartigerweise verwenden weder wir noch unsere Kunden nur C++ (also wir überhaupt nicht). Ich finde es auch eigenartig, dass viele Banken auf Java umsteigen, scheint so, dass die Finanzwelt da irgendwie etwas nicht begriffen hat oder sich nur unfähige Programmierer leisten kann...

Oh Schreck, die Messungen der Mondfähre der NASA wurden mit einem JAVA-Programm ausgewertet. Die Leute da sind komplett unfähig, ich sehe es ein.

Ideologisch motiviertes Bastelwerk, halbherzig zusammengeschustert durch praxisfremde Marketingstrategen mit Zwangs-OOP-Fixierung, hat keinerlei Chance, will man sich tagtäglich aufs Neue den Herausforderungen der Globalisierung und der mit dieser einhergehenden ständig wechselnden Anforderungen an das Entwicklungswerkzeug erfolgreich stellen. Da können einfach nur Lösungen von Profis für Profis zum Einsatz kommen, die hervorragend durch das Stroustrupsche Meisterwerk abgedeckt werden.

Aha, Globalisierung = C++. Müssen wir den Globalisierungsgegner mitteilen, damit sie mal C++ boykottieren können...

Und wer irgendwann nur einmal das Buch von Stroustrup (das Original von ihm) gelesen hat, wüsste, dass er sich wegen solcher idiotischen Aussagen im Grab drehen würde. Ihm ging es nämlich nicht um Idealismus, wie den gewisse C++-Entwickler und Java-Entwickler (von den .NET Leuten gar nicht zu sprechen) an den Tag legen, sondern um Entwicklung der Programmierung im Allgemeinen. Ich programmiere sowohl in der Java-Welt, wie auch in der C++-Welt und sehe nicht ein, warum man nicht beides programmieren kann. Beide haben ihre Vor- und Nachteile, wobei Performance sowieso noch etwa in einem Promille der Software eine Rolle spielt und dort nicht selten nicht einmal C++ zum Einsatz kommt, sondern sogar noch der "Vorgänger" C. Denn dies ist dann wirklich performant.

 

[gast]

Ich programmiere sowohl in der Java-Welt, wie auch in der C++-Welt und sehe nicht ein, warum man nicht beides programmieren kann.

Ja, alle 3 Sprachen/Frameworks haben ihre Berechtigung. C/C++ für performante Software wo es auf schnelle Implementierungen von Algorithmen ankommt. Wie bei Codecs, Filtern, Transformationen, Steuern und Messen, Text- und Kalkulationssoftware die große Datenmengen zu bewältigen haben, Datenbanken, Webserver, Treiber, Betriebssysteme. Software die im Hintergrund äuft wie Virenscanner man möchte das eine Anwendung den Rechner nur das nötigste an Resourcen abknöpft.

JAVA ist auch so eine Software und ja auch ein Kind von C++.

Beide haben ihre Vor- und Nachteile, wobei Performance sowieso noch etwa in einem Promille der Software eine Rolle spielt und dort nicht selten nicht einmal C++ zum Einsatz kommt, sondern sogar noch der "Vorgänger" C. Denn dies ist dann wirklich performant.

Stimmt C ist nochmal ein Stück performanten in einigen Fällen als C++, aber hat auch dazu beigetragen die Sicherheitslücken die die CLibs mitbringen auch automatisch auf C++ zu übertragen. Vielen ist der Unterschied beider Sprachen garnicht klar. Es wird aber immer noch sehr viel in C programmiert siehe WinAPI oder Linuxkernel.

 

[Gast2]

Stimmt schon, Swing ist etwas träge. Das kommt daher, dass Swing plattformunabhängig ist. Es wird halt nicht das native Fenstersystem des OS benutzt. Da gibt es aber wohl sehr interessante Neuerungen in Java 1.6. Als Alternative existiert schon lange SWT. Damit kannst Du GUI Anwendungen mit Java bauen, die die nativen Widgets des OS benutzt. Paradebeispiel: Eclipse.

Es mag schon sein, dass SWT ein bischen Performance bringt und es mag auch sein, dass sich eine SWT-GUI "nativer" anfühlt. Aber irgendwie bin ich der Meinung, dass es das nicht wert ist. Ich musste mal etwas mit SWT arbeiten und habe da den Eindruck erhalten, dass die Bedienung von SWT zum k***** ist. ...für den Entwickler meine ich. Zudem muss man sich bei SWT um Dinge kümmern, die Java-untypisch sind. Resourcenmanagement usw.. Und als Sahnehäubchen kommt dann auch noch, dass man seine Software für jede Plattform getrennt anbieten muss und die jeweils passende SWT-Version dazupacken muss. Das alles führt bei mir zu dem Eindruck, dass SWT nicht wirklich zu Java passt.

Da bin ich dann eher für Swing, auch wenn das vielleicht ein paar Nachteile bei der Performance und dem L&F bietet. Ich weiß, dass Sun da stetig dran arbeitet und ich bin da wohl auch relativ geduldig mit Sun. ...zumal mir da noch nie ein echtes Problem aufgefallen ist, das Swing für mich unbenutzbar machen würde.

Und insofern denke ich auch, dass SWT letztendlich nur eine relativ kurz andauernde Modeerscheinung ist. SWT hat auf Dauer keine Existenzberechtigung. ...IMHO.

 

[HugoBoss]

Java wird immer mehr zusammengefrickelt. Zu viele Technologien und keiner weiß auf was er setzen soll. Schade eigentlich hät was tolles aus Java werden können, aber es wird eh bald von .NET jedenfalls unter Windows abgelöst.

Java ist derzeit was für Studenten/Praktikanten und Hobbyprogrammierer die leider sich als professionelle Softwareentwickler ausgeben und so die Kunden übern Tisch ziehen. Im Serverbereich sieht die Sache etwas anders aus.

 

[byte]

Es mag schon sein, dass SWT ein bischen Performance bringt und es mag auch sein, dass sich eine SWT-GUI "nativer" anfühlt.

SWT-GUIs sind nativ, sie fühlen sich nicht nur so an. Alle Widgets werden vom Betriebssystem gezeichnet und verwaltet. Daher auch der Mehraufwand des disposens, denn der GC ist dazu eben nicht in der Lage. Der Performance Gewinn von SWT gegenüber Swing, was die Trägheit der GUI angeht, ist eben genau das, was so viele C/C++ Programmierer Java Desktop Anwendungen ankreiden. Daher habe ich das hier angeführt.

Aber irgendwie bin ich der Meinung, dass es das nicht wert ist. Ich musste mal etwas mit SWT arbeiten und habe da den Eindruck erhalten, dass die Bedienung von SWT zum k***** ist. ...für den Entwickler meine ich. Zudem muss man sich bei SWT um Dinge kümmern, die Java-untypisch sind. Resourcenmanagement usw.. Und als Sahnehäubchen kommt dann auch noch, dass man seine Software für jede Plattform getrennt anbieten muss und die jeweils passende SWT-Version dazupacken muss. Das alles führt bei mir zu dem Eindruck, dass SWT nicht wirklich zu Java passt.

Sicher ist SWT anders als z.B. Swing. Selbst erzeugte Widgets müssen explizit entfernt werden. Plattformunabhängigkeit ist imo genauso bedingt gegeben wie bei Java selbst. Sicherlich ist das ein interessanter Aspekt, aber mal im Ernst: Wann kommt eine Software bitte schonmal auf jedem OS zum Einsatz? Java läuft auch nur auf den Systemen, für die es ein JRE gibt. Es läuft nicht per se auf jedem System. Das gleiche trifft auf SWT gesondert zu. Es läuft auf jedem System, für das die SWT Wrapper existieren. Das wären zur Zeit: Windows, Windows CE, Linux, Solaris, QNX, AIX, HP-UX und Mac OSX. Wieviel Prozent der Desktop-Software wird für andere Systeme entwickelt?

Und nun ja, dass Du die "Bedienung" von SWT fürn Po findest, das liegt wohl eher an Dir selbst. :roll:

Und insofern denke ich auch, dass SWT letztendlich nur eine relativ kurz andauernde Modeerscheinung ist. SWT hat auf Dauer keine Existenzberechtigung. ...IMHO.

Also als Modeerscheinung würde ich SWT nun wirklich nicht betrachten. Das Framework gibt es mittlerweile seit über 5 Jahren, was in der IT Welt schon eine halbe Ewigkeit ist. Es wird seitdem stetig weiterentwickelt und bietet mit JFace eine imo starke Weiterentwicklung, nicht zuletzt weil es MVC beim Entwickeln fördert. Und RCP mausert sich zu einem sehr mächtigen Framework für die Entwicklung von nativen Rich Client Anwendungen mit hoher Funktionalität, Wiedererkennungswert bei vergleichsweise niedriger Entwicklungszeit.

SWT und Swing können imo prima nebeneinander existieren. SWT eröffnet auch in Java die Möglichkeit, native GUI-Anwendungen zu bauen - ein Punkt, der Java sonst immer wieder angekreidet wird. Wer keine native GUI braucht oder möchte, der kann ja gerne bei Swing bleiben.

 

[Beni]

Es mag schon sein, dass SWT ein bischen Performance bringt und es mag auch sein, dass sich eine SWT-GUI "nativer" anfühlt. Aber irgendwie bin ich der Meinung, dass es das nicht wert ist. Ich musste mal etwas mit SWT arbeiten und habe da den Eindruck erhalten, dass die Bedienung von SWT zum k***** ist. ...für den Entwickler meine ich. Zudem muss man sich bei SWT um Dinge kümmern, die Java-untypisch sind. Resourcenmanagement usw.. Und als Sahnehäubchen kommt dann auch noch, dass man seine Software für jede Plattform getrennt anbieten muss und die jeweils passende SWT-Version dazupacken muss. Das alles führt bei mir zu dem Eindruck, dass SWT nicht wirklich zu Java passt.

Es ist übrigens nicht notwendig (und spricht auch nicht für den Kopierer), Beiträge aus anderen Foren hierherzukopieren... Wir lesen sowas lieber im Original, wie in diesem Thread .

 

[AlArenal]

 

[Gast]

Hoi der Gui Frickler AlArenal, der lieber auf Rechschreibung und Ausdruck achten als sich mit der Sache auseinanderzusetzen, haut hier eine Grafik von Sun rein. Respekt...Toll gemacht...Du bist ein Held...Schön das es von solchen Pseudoinformatikern nicht mehr gibt.

 

[AlArenal]

Ein Bild sagt bekanntlich mehr als tausend Worte - vor allem wenn jemand wie du offensichtlich mit dem Lesen auf Kriegsfuß steht. Wer ein wenig mehr auf dem Kasten hat, merkt ganz von selbst, dass die Grafik mit einem Artikel verlinkt ist.

Hatte ich dich eigentlich schon gefragt, was du beruflich so treibst? Oder kann man mit Trollerei heutzutage schon Geld verdienen?

 

[Guest]

Ich stehe nicht mit dem Lesen auf Kriegsfuss ich tippe leider sehr schnell und lese mir das gechrieben selten nochmal durch bevor ich abschicke. Du bist der Einzige der sich da mehr für die Form als für den Inhalt interessiert, das macht Dich unsympatisch, aber darum geht es hier ja garnicht.

Damit Du vor Neugierde nicht platzt, ich bin Webentwickler und habe auch ab und an mit Administration von Windows und Lunix zu tun. Naja wie es in einer kleinen Firma halt so ist muss man oft vieles machen, bevor dem Chef dann mal die Idee bestimmte Aufgaben, die zu viel Zeit kosten, auszulagern. Auf Arbeit kommt viel C, PHP und ein wenig JAVA zum Einsatz.

 

[byte]

Deine Flames kannst Du Dir echt mal stecken. Wenn Dir die Argumente ausgehen, dann klick lieber oben rechts aufs X. Wir sind hier nicht im Kindergarten...

 

[AlArenal]

Wie dem auch sei habe ich recht wenig Lust mich weiterhin mit Gast1 bis GastX zu unterhalten. Da wird man ja noch ganz kirre von und zudem kann man sich des Eindrucks nicht erwehren verarscht zu werden.

Weiterhin sehe ich nicht warum ich mich als Therapeut für Verfolgungswahn und Dogmatismus anderer versuchen muss. Ich habe kein Problem mit anderen Sprachen und den zugehörigen Entwicklern. Ich habe ein Problem damit wenn jemand eigene Ignoranz und Borniertheit mit Stolz vor sich herträgt, als handle es sich um die Bundeslade - im Glauben dadurch argumentativ unbesiegbar zu sein.

Dummerweise bestehen viele Pseudoargumente nur aus "ich glaube" und "ich behaupte", angereichert mit einigen Totschlagargumenten, die völlig am Thema vorbeigehen. Wenn einige meinen C++ sei der Weisheiut letzter Schluss in allen Lebenslagen, sollen sie dabei bleiben. Wenn sie meinen der Otto-Normal-Anwender würde nen Dreck drauf geben ob eine Anwendung ein paar Prozent schneller reagiert, während sie die meiste Zeit eh nur darauf wartet, etwas zu tun zu bekommen - ich hindere niemanden daran.

Aber seid doch bitte nicht so blöde anderen und mir einreden zu wollen, dass das was wir seit Jahren beruflich schaffen, gar nicht möglich sein soll.

Frei nach Dieter Nuhr:
"Wenn man keine Ahnung hat, einfach mal Fresse halten!"

Drüber diskutieren ist überhaupt kein Problem, aber wenn klar wird, dass das Gegenüber absolut lernresistent ist und einfach nur seinen ewig gestrigen Scheiß loswerden will, habe ich nur noch einen Tipp: Geh auf die nächste Autobahn und spiel mit den Autos!

 

[Gast]

Wenn niemand auf die Flames eingehen würden, dann würde ich mir den Spass auch nicht machen.
Aber ihr springt immer soooo schön drauf an, als wenn man in eine Wunde bohrt. Is einfach nur schööööön.

Mal im Ernst, mich kotzen die Vorurteile gegen C++ genauso an wie euch dieselbigen gegen Java.

Zu einem Endergebnis kommt man bei so einem Flame zwar nicht, aber ich habe doch das Eine oder Andere über die jeweilige Sprache gelernt. Bin halt sehr Wissbegierig, da ich in beiden Sprachen mal entwickeln möchte. Sone Flames helfen ein wenig die Einsatzbereiche der beiden Sprachen besser abzustecken. Auf Aussagen von SUN als BigPlayer hinter Java gebe ich genauso wenig, wie auf Aussagen von dem direkten Konkurrenten .Net von M$ im Desktopsektor.

Die Gemüter etwas anzuregen bringt erstaunliche Threads zustande, wo die Leute mal wirklich über die Vorurteile nachdenken und vielleicht auch mal überdenken.

Auf der einen Seite gibt es die, die man als Extremisten der jeweiligen Sprache bezeichnen könnte aber auch Andere die die jeweiligen Schwächen und Stärken genau kennen und sich auch nicht persönlich angegriffen fühlen wenn die Schwächen angesprochen werden. Und genau die Sorte Entwickler sind interessant für solche Themen. Vor allem für die Totaleinsteiger die jedem Benchmark und jeder Statistik vertrauen weil sie es nicht selbst an ihrem Rechner austesten können.

So nun könnt ihr den Rotstift ansetzen...

 

[AlArenal]

Vollkommener Dummfug, was du da über Flames schreibst. Genauso hirnrissig, wie wenn ich sagte "Einfach mal irgendwo einmarschieren und Krieg führen hilft die Kultur fremder Länder kennenzulernen.". Wenn du eine Sprache lernen willst, lerne sie und arbeite damit. Unterhalte dich in ordentlichem Ton mit denen, die dir was zu sagen haben. Wenn du ein Mädel kennenlernen willst, gehst du ja auch nicht hin und sagtst "Ey, du siehst scheiße aus und wahre Liebe gibts nur unter Männern. Erzähl mir was von dir!".

Du hast einfach nur nen ganz schweren Dachschaden, das ist alles.

 

[Gast]

Ich habe mein Ziel erreicht der Thread kann geschlossen werden. Dank an AlArenal der zwar wenig Sachliches aber viele amüsante Abstraktionen drauf hat. Ich hoffe Du macht nicht viel mit OOP *kicher. Bist bestimmt nen ganz junger Spunt, aber freu dich aufs älter werden. Da siehts du vieles lockerer und auch aus einem ganz anderen Blickwinkel.

 

[AlArenal]

Jaja, ich bin ein ganz junger.... "Jung" genug um die alten Zeiten herbeizusehnen, als solch ätzendes Verhalten wie deines zur virtuellen Steinigung führte. Leider kommt mittlerweile jeder Idiot ins Netz und kann sich hinter einem Pseudonym oder Gast-Account verstecken, um seine Persönlichkeitsdefizite zur Schau zu stellen.

Der heftige Preis der Freiheit.

 

[AlArenal]

http://www.shudo.net/jit/perf/
http://www.osnews.com/story.php?news_id=5602
http://www.jot.fm/issues/issue_2003_09/column3

 

[0xdeadbeef]

Ich hätte die Möglichkeit, als Gast zu posten schon lange entfernt. Die Nachteile (Spam und feige Trolle) überwiegen die Vorteile bei weitem. Außerdem passiert es ständig, daß Leute übersehen, daß sie nicht eingeloggt sind und dann aus Versehen als Gast posten.

 

[AlArenal]

http://blogs.sun.com/roller/page/dagastine?entry=sun_java_is_faster_than1

 

[personenkult]

Ach guck, mal wieder ein Java vs. C++ Thread Für gewöhnlich sollte man sich nicht auf ein solches Level herablassen, dass man es nötig hat eine Programmiersprache zuverteidigen.
Der Ablauf ist eh immer der gleiche. Am Anfang wird noch lustig geschwafelt, zur Mitte hin kommen die ersten Performancetests, am Ende bleibt nur noch die persönliche Ebene.

Trotzdem ist C++ schneller als Java. Gruß an "Volkard". ;-)

 

[justchris]

Ja...C++ ist schneller als Java, da können noch soviele Benchmarks, die von Javavertretern wie SUN was anderes sagen. Aber darum geht und ging es ja auch nie bei Java. Es geht auch nicht unbedingt um Plattformunabhängigkeit, denn C++ ist auch nicht auf irgendein System festgelegt und es gibt genügend Libs und Frameworks für alles Mögliche für verschiedene Plattformen.

Java verdankt seiner Beliebtheit dem schnellen Erfolg beim Entwicklen mit inzwischen akzeptaler Geschwindigkeit. Es steht weniger die Technik des jeweiligen Systems im Vordergrund, sondern das Konzentieren auf die Problemlösung der Anforderung. Die ausgezeichnete Dokumentation und die vielen schon standartmäßigen Klassen sparen viel Zeit bei der Entwicklung.

Ein Entwickler wählt eh immer für das jeweilige Problem die richtige Sprache sei es nun Shellscripts, C/C++, C#/.Net/ PHP, Phyton , VBA, Delphi oder halt Java. Es werden auch ganz bestimmt noch mehr Sprachen kommen, wer sich stur nur auf eine Sprache beschränkt und nicht bereit ist irgendwann mal was anderes ausprobieren der verliert eh irgendwann den Anschluss. Mann sollte auch nicht versuchen alles mit einer Sprache zu realisieren nur weil man halt ein fanatischer "Fan" seines Lieblings ist, denn darunter leidet nur das Endprodukt.

Gruß Chris

 

[AlArenal]

Ein Entwickler wählt eh immer für das jeweilige Problem die richtige Sprache sei es nun Shellscripts, C/C++, C#/.Net/ PHP, Phyton , VBA, Delphi oder halt Java.

Jein. In Sprachen, die ich kaum oder gar nicht beherrsche, kann ich Aufwände auch nicht abschätzen. Also tendiert man eher dazu seine vorhandenen Ressourcen zu nutzen, um ein Problem zu lösen. Ruby on Rails beispielsweis eist ein beedinruckendes Framework auf Basis einer sehr interessanten Sprache. Bevor man aber die Eigenheiten beider in ähnlichem Umfang kennt und beherrscht, wie man es vielleicht bei PHP oder Java kann (weil man bisher mit denen gearbeitet hat), vergeht Zeit und die hat man im Job meist nicht.

Nehmen wir doch nur Java selbst als Beispiel. Die Syntax zu beherrschen und die API auswendig zu kennen sagt noch nichts drüber aus, wie effektiv und mit welcher Qualität man eine komplexe Anwendung designt und umsetzt. Wenn ich in ner Firma sitze, wo ich eh der einzige Coder bin und mir aussuchen kann in was ich meine Sachen code isses schön, aber in der Regel wird man immer auf vorhandenes Know-How setzen und allzu exotische Lösungen vermeiden.

Der Standardspruch "Kannst du eine Sprache, kannst du alle" birgt bei Programmierern nicht viel mehr Wahrheit, als bei jedem anderen Menschen. Nach Deutsch und Englisch wirds zumindest bei mir schon langsam dünn...

 

[justchris]

Klar ist es einfacher den Aufwand für ein Softwareprodukt abzustecken, wenn man in der Sprache programmiert der man die meiste Zeit gewidmet hat. Aber nicht jeder wird in so einer Position eingestellt, also kann man hier auch nicht auf die Allgemeinheit schließen. Es gibt da auch noch die andere Seite der "Allrounder", der zwar in keiner Sprache so gut ist wie ein Experte in einer Einzelnen es ist, aber dafür einen besseren Überblick über die Möglichkeiten hat, die es sonst noch so gibt. Für beide Sorten Programmierer gibt es Arbeit und man sollte auch hier nicht schwarz weiss denken, sondern auch die viele Graustufen dazwischen sehen und nicht übersehen.

Der Standardspruch "Kannst du eine Sprache, kannst du alle" birgt bei Programmierern nicht viel mehr Wahrheit, als bei jedem anderen Menschen. Nach Deutsch und Englisch wirds zumindest bei mir schon langsam dünn...

Dieser Spruch bezieht sich aber nur auf die Abtraktion von Problemlösungen in die Prozeduale- oder OO-Programmierung. Das Design ist ja hier sehr entscheident über z.B die Schnellig- und Wartbarkeit der Software. Die Implementierung der Lösung, in welcher Sprache auch immer, gehört ja zu den letzten Schritten in der Produktion. Es ist wenig mir der Erlernung einer verbalen Sprache zu vergleichen. Wer einmal in einer Sprache ein größeres Produkt entwickelt hat, der hat schon einen gutes Stück der allgemeinen Softwareentwicklung verstanden. Und dieses Wissen erleichtert den Einstieg in eine andere Programmiersprache schon enorm. Syntax(mal abgesehen von Perl ), andere Libs oder Plattformen werden dann wesentlich schneller erlernt.


Gruß Chris

 

[AlArenal]

Letzten Endes sitzt du aber nunmal an der Implementierung und du kannst nicht unbedingt ein Design schaffen, dass dann in einer beliebigen Sprache umsetzbar ist, zumal die Entscheidgun für eine bestimmte Sprache ja wohl auch aus der Motivation erfolgt dessen besondere Stärken nutzen zu wollen.

 

[0xdeadbeef]

Ja...C++ ist schneller als Java, da können noch soviele Benchmarks, die von Javavertretern wie SUN was anderes sagen.

Das ist schon deshalb Quatsch, weil C++ ja nur eine Sprache ist (die man theoretisch auch interpretiert ausführen könnte). Richtiger müßte es heißen: "Optimierter nativer Code, wie ihn ein guter C++-Compiler bei entsprechender Programmierung erzeugen kann, ist mindestens genauso schnell wie von einer JVM ausgeführter prozessorunabhängiger Bytecode."

Dazu kommen noch spezifische Merkmale von Java, die die Geschwindigkeit drücken können, in erster Linie wären das der Zugriff auf Arrays, der bei Java durch das Prüfen der Grenzen stark ausgebremst wird und Collections von Basistypen, für die man in Java zwingend Wrapperklassen benötigt. Ein Problem für Echtzeitanwendungen ist die Garbage Collection, die zudem denn Footprint bezüglich Speicheranforderungen hochtreibt.
Last but not least kommen in der Laufzeitumgebung noch die Abstraktionsschichten für alle Hardwarezugriffe dazu, die einen erheblichen Overhead erzeugen können.

Man kann daher mit Leichtigkeit Beispiele finden, bei denen ein in Java entwickeltes Programm dramatisch langsamer ist als nativer Code, der von einem C++-Compiler erzeugt wurde. Auf der anderen Seite gibt durchaus viele Szenarien, bei denen sich Java- und C++-Programme nicht viel geben.

Kurioserweise sind übrigens meist die Leute, die Java grundsätzlich ablehnen, weil es ja interpretiert (was so eh falsch ist) und langsam ist, ohnehin nicht in der Lage, performanten C++-Code zu schreiben. Auch da muß man nämlich sehr aufpassen, daß man sich nicht mit dauernden Konstruktor/Desktruktor-Aufrufen verhebt.

Zudem ist die Performance halt nicht das einzige Kriterium. Nur mal als Beispiel: praktisch jede von Privatleuten geschriebene MFC-Komponente hatte Speicherlecks, zweifelhaftes Exceptionhandling und die Neigung zu unmotivierten Abstürzen. Von Normalusern geschriebene Swing- oder SWT-Komponenten sind dagegen in aller Regel unproblematisch. Lag sicher auch zum Teil an der MFC, aber es erfordert in C++ halt auch viel mehr Disziplin, eine saubere Klasse zu schreiben. Von der Dokumentation ganz zu schweigen: jeder ambitionierte Javaprogrammierer setzt selbstverständlich Javadoc ein, weil es ja quasi zum Sprachumfang gehört. Dagegen sieht man Doxygen o.ä. bei privaten C++-Projekten praktisch nie.

 

[flashdog]

Versuch doch mal gcj ( http://gcc.gnu.org/java/ ) dort wird der Java code native übersetzt. Ausserdem bietet gcj auch eine native schnittstelle CNJ. In CNJ wird c++ programmiert.

gcj unterstützt auch GTK ( http://people.redhat.com/overholt/nativeeclipse/index.html ). GTK ist eine GUI für viele Programmiersprachen.

Es gibt auch noch TCL/TK.

Ich glaube assmebler war das schnellste.

 

[0xdeadbeef]

Versuch doch mal gcj ( http://gcc.gnu.org/java/ ) dort wird der Java code native übersetzt. Ausserdem bietet gcj auch eine native schnittstelle CNJ. In CNJ wird c++ programmiert.

Man sollte aber nicht erwarten, daß das eine spürbare Geschwindigkeitssteigerung bringt. der JIT-Compiler der letzten JVMs ist schon recht gut. Es steht auch zu befürchten, daß die Programme recht riesig werden, was den Vorteil der Unabhängigkeit von der JRE (sofern das überhautp der Fall ist) wieder entkräftigt. Außerdem ist es nun mal ein Grundprinzip von Java, daß man Klassen zur Laufzeit nachladen kann. Was mit einem nativ kompilierten Programm entweder nicht mehr so recht geht oder zumindest keinen übertriebenen Sinn mehr ergibt.

gcj unterstützt auch GTK ( http://people.redhat.com/overholt/nativeeclipse/index.html ). GTK ist eine GUI für viele Programmiersprachen.
Es gibt auch noch TCL/TK.

Also ein Programm in Java mit GTK zu schreiben und dann nativ zu kompilieren ist irgendwie wie sich mit dem linken Fuß am rechten Ohr zu kratzen. Wenn man unbedingt ein natives Programm will, nimmt man halt C++, will man ein plattformunabhängiges, nimmt man Java. So what? Wenn man erst mal eine Programmiersprache beherrscht, ist es doch kein großes Ding, sich eine andere anzueignen.

Ich glaube assmebler war das schnellste.

Blahfasel. Erstens gibt es eigentlich kein Assembler als Programmiersprache. Pro Prozessor gibt es jeweils ein paar ASM-Dialekte. Das ganze ist syntaktisch usw. dermaßen unstandardisiert, daß dagegen selbst Basic wie ein Freudenquell für Normierungsfreudige wirkt. Und dann ist es ein großes Mißverständnis, daß ein in Assembler geschriebenes Programm per se schnell ist. Gerade bei den heutigen Prozessoren kann man da extrem viel falsch machen und am Ende ist ein handgestricktes, sauber aussehendes und optimal kurzes Programm oft lahmer als eines, daß ein C/C++-Compiler erzeugt hat. Wer schon mal versucht hat, die diversen Pipelines und parallelen Recheneinheiten eines modernen Prozessors (von RISC mal ganz zu schweigen) auszunutzen, weiß von was ich spreche.

 

[DEvent]

Blahfasel. Erstens gibt es eigentlich kein Assembler als Programmiersprache. Pro Prozessor gibt es jeweils ein paar ASM-Dialekte. Das ganze ist syntaktisch usw. dermaßen unstandardisiert, daß dagegen selbst Basic wie ein Freudenquell für Normierungsfreudige wirkt. Und dann ist es ein großes Mißverständnis, daß ein in Assembler geschriebenes Programm per se schnell ist. Gerade bei den heutigen Prozessoren kann man da extrem viel falsch machen und am Ende ist ein handgestricktes, sauber aussehendes und optimal kurzes Programm oft lahmer als eines, daß ein C/C++-Compiler erzeugt hat. Wer schon mal versucht hat, die diversen Pipelines und parallelen Recheneinheiten eines modernen Prozessors (von RISC mal ganz zu schweigen) auszunutzen, weiß von was ich spreche.

:toll:
Alles wird doch eh in den Assembler (und dann Maschinencode) übersetzt. Da ist es doch egal ob man Java/C++ oder sonstwas verwendet.
Entscheident sind die Vorteile/Nachteile der jeweiligen Sprache und den Overhead den der Compiler erzeugen muss, damit die Anforderungen der Sprache gerecht werden. Also sowas wie Type-Checking, Virtuelle Vererbung, das Vertecken der Speicherverwaltung....
Wichtig ist doch nur das das Verhältniss von Vorteilen/zusätzlicher Code in maßen bleibt. Dabei sollte man immerwieder die 80/20 Regel erwähnen. In den bisschen Code das wirklich Zeitkritisch ist, gibts sich Java und C++-Programme nicht viel.
Ausserdem ist in der heutigen Zeit der Algorithmus viel wichtiger, als micro-Optimierungen. Wenn ein Algo statt in O(n²) in O(2^n) läuft nützt auch der beste Assembler-Guru nichts. Um das Designen von Algos zu vereinfachen (also den Code auf das Wichtigste zu reduzieren) wurden solche Hochsprachen wie Java erfunden. Der Erfolg dieser Sprachen gibt also dem Prinzip recht, weg von Nullen und Einsen, hin zu mehr Abstraktion.
Die Entwicklung des Computers lässt sowieso kein "von Hand gemachten" Optimierungen zu. Früher war es einfach den Code für eine Maschine zu 99,99% per Hand zu optimieren. Weil man sich sicher war, dass das Programm in den nächsten Jahrzenten nur auf dieser Maschine läuft. Heutzutage gibt es mehr als 1000 Prozessorarten. Da ist es schlicht nicht mehr möglich für alle Prozessoren optimal zu optimieren. Deswegen bin ich ein Beführworter des JIT-Compilers. Der JIT kann (theoretisch oder praktisch) für die Maschine optimieren, auf der das Programm grade läuft. Das kann kein nativer Compiler. Nichts optimiert die .exe Dateien die so ein Compiler erzeugt und meistens compiliert man doch eh für eine Standard-32 Bit-Maschine.

 

[0xdeadbeef]

Alles wird doch eh in den Assembler (und dann Maschinencode) übersetzt. Da ist es doch egal ob man Java/C++ oder sonstwas verwendet.

Diesen Zwischenschritt macht kaum ein Compiler heuzutage. Ist aber eh völlig irrelevant.
Ich finde es nur immer wieder erschütternd, wenn Leute, die noch keine Zeile in irgendeinem Assembler-Dialekt geschrieben haben, davon reden, wie schnell doch Assembler ist.

Ansonsten stimmen wir ja prinzipiell überein. Mal davon abgesehen, daß man schon explizit sagen muß, daß Java Sprachmerkmale hat, die einer optimalen Performance in bestimmten Bereichen im Wege stehen. Wenn man z.B. in einem Bitmap als "Array of Int" tausend Pixel manipuliert, wird tausendmal der Index auf Über-/Unterlauf überprüft. Jetzt mal ganz davon abgesehen, daß die Pixelzugriffe an sich durch die Abstraktion von der tatsächlichen Speicherung in der Graphikkarte nochmal ernorm viel mehr Laufzeit brauchen als bei einer hardwarenahen Implementierung in C/C++: alleine das Überprüfen der Arraygrenzen bei jedem Zugriff vervielfacht die Laufzeit.
Da kann der JIT-Compiler noch so gut sein: trotzdem wird ein Java-Programm bei sowas immer sehr viel langsamer sein als ein (optimal programmiertes) C/C++-Programm.

Aber auch dieses "Problem" ist halt das Resultat eine Güterabwägung: in einem "normalen" Programm überwiegen die Probleme, die durch falsche Arrayzugriffe resultieren, deutlich den Nachteil geringerer Laufzeit. Die beliebten Buffer-Overflow-Probleme, die in jedem zweiten C/C++-Programm vorkommen, sind damit in Java ausgeschlossen (solange man keinen Overflow in der JVM erzeugt, die ja wiederum in C++ geschrieben ist). Außerdem gestaltet sich auch die Fehlersuche in einem Java-Programm deutlich leichter.

Auch der ganze Themenbereich Präcompiler/Templates vs. Java Generics zeigt, daß man seitens Sun immer auf die sichere Seite statt auf Geschwindigkeit setzt.

Einen Tod muß man halt sterben.

 

[flashdog]

Vergleich von java, gcj, gcc und c# (
http://blog.planetxml.de/archives/27-Primzahlen-berechnen-in-C,-C-und-JAVA.html )

 

[tuxedo]

Weil ich eben mal zu viel zeit hatte hab ich mir das ganze "gesülze" mal durchgelesen.

Ist schon recht amüsant wie sich beide Seiten hinter dicken Mauern verstecken.

Ich selbst bin leidenschaftlicher Java-Programmierer.

Während meines Studiums durfte ich mich an Java, C, C++ und C# Programmen vergreifen.
Mir persönlich hat Java in jeder Hinsicht besser gefallen. Nicht nur weil die IDE Eclipse intuitiv ist und nix kostet.

VS2005 fand ich im vergleich zu Eclipse fast schon hinderlich. Aber es geht hier ja nicht um IDE's sondern um die gegensätzlichen Fronten.

Ich muss AlAernal schon recht geben. Java ist nicht so langsam wie es immer hingestellt wird. Auch Programme mit Swing sind nicht langsam. Sie sind nur meist schlecht programmiert (Stichwort Threads, Swingworker etc.).

Mit der veröffentlichung von Java6 hat sich viel getan. In der c't gabs nen Artikel darüber. Darin stand, sinngemäß, dass in einzelnen Fällen Java-Programme bis zu 50% schneller starten wenn sie mit Java6 compiliert wurden statt mit Java5.

Nun ja. Man kann nicht Äpfel mit Birnen vergleichen. So bin ich auch der Meinung man kann C/C++ nicht mit Java vergleichen. Okay, in Benchmarks geht das schon, aber ist das repräsentativ?

Erinnert sich noch jemand an das alte "Quake I" von idSoftware? Ja? Das (die Engine) wurde mittlerweile in Java implementiert. Man muss dazu sagen dass die Grafik nach wie vor native umgesetzt ist da Java hier keinen direkten Zugriff hat.
Und dazu gibt es auch Benchmarks:

http://bytonic.de/html/benchmarks.html

Wenn Java jetzt wirklich langsamer sein sollte als C, warum gibt es dann ne Konstellation in der Java C um 5..10 Frames schlägt?

Egal.
Ich würde sagen: Wer C/C++/C# bevorzugt lässt die Finger von Java und umgekehrt.

Das ist wie das alte Leid "Windows ist besser als Linux / Linux ist besser als Windows"....

Es gib vor beide Seiten Vor- und Nachteile. Welche für den einzelnen überwiegen lässt sich nicht globalisiert sagen.
Für jeden Anwendungszweck gibts eine Lösung. Für den einen ist es Java, für den anderen die C-Derivate.

Und zuguter letzt noch ein Wort von wegen "Java stirbt aus". IMHO ist dem nicht so. Zumal viele große und namhafte Firmen (aus eigener Erfahrung sei hier Daimler Chrysler genannt) Java in einigen Bereichen bevorzugen. Nicht in allen, aber in einigen.

In diesem Sinne,

Gruß
Alex

 

[SlaterB]

Ich muss AlAernal schon recht geben. Java ist nicht so langsam wie es immer hingestellt wird.
[..]

Mit der veröffentlichung von Java6 hat sich viel getan. In der c't gabs nen Artikel darüber. Darin stand, sinngemäß, dass in einzelnen Fällen Java-Programme bis zu 50% schneller starten wenn sie mit Java6 compiliert wurden statt mit Java5.

irgendwie widersprechen sich solche Aussagen,
oder zumindest beim Programstart muss doch Java dann 'irgendwann mal langsam gewesen sein'

 

[tuxedo]

Ich muss AlAernal schon recht geben. Java ist nicht so langsam wie es immer hingestellt wird.
[..]

Mit der veröffentlichung von Java6 hat sich viel getan. In der c't gabs nen Artikel darüber. Darin stand, sinngemäß, dass in einzelnen Fällen Java-Programme bis zu 50% schneller starten wenn sie mit Java6 compiliert wurden statt mit Java5.

irgendwie widersprechen sich solche Aussagen,
oder zumindest beim Programstart muss doch Java dann wengistens 'irgendwann mal langsam gewesen sein'

Was widerspricht sich denn da? Java wird, wie alle anderen Sprachen auch, fortwährend verbessert und optimiert.
Sowohl C als auch Java waren vor Jahren langsamer als jetzt.

Der Bezug auf den Artikel in der c't sollte nur verdeutlichen dass Java nicht schläft und sich anstrengt noch mehr Performance aus sich raus zu holen.
Vor Jahren galt wirklich noch: Java ist furchtbar langsam und speicherfressend. Nur leider hat sich das in den Köpfen eingebrannt und hängt da immer noch drin.

Java ist nichtmehr so langsam und so speicherfressend wie früher. Was jetzt nicht heissen soll dass Java besser als C ist.
Ne, es soll nur heissen Java ist besser geworden.

Ich stell mich auf keine Seite, weder auf C noch auf Java-Seite wenn es um die Performance im direkten Vergleich geht. Ich steh da lieber dazwischen und schau zu wie die Fetzen fliegen.

Ein grottenschlechtes Java-Programm ist ganz klar schneller als ein gut geschriebenes C-Programm. Das gleiche gilt auch andersrum.
Und da wir wohl alle keine Programmiergötter sind wage ich mal zu behaupten dass man deshalb nicht generell sagen kann: Java ist schneller/besser als C (und umgekehrt).

Es hängt immer vom können des jeweiligen Programmierers ab was das Programm letztendlich leistet (oder nicht leistet).

- Alex

 

[SlaterB]

diese Argumentation funktioniert aus einem gewissen Blickwinkel immer noch nicht,
wenn sich eh alle Sprachen (auch zusammen mit der Hardware) stetig verbessern, warum dann 'hat sich viel getan'?

dann ist doch gar nix passiert, nur (im Vergleich zu anderen Sprachen) der Status Quo gehalten..

andereseits sagst du nun wieder
'dass Java nicht schläft und sich anstrengt noch mehr Performance aus sich raus zu holen.',
'Java ist nichtmehr so langsam und so speicherfressend wie früher'

also war es doch irgendwann mal langsamer als jetzt,
falls nicht auch die gleichen Aussagen auf C++ zutreffen
(zumindest eine Aussage 'C++ ist nichtmehr so langsam und so speicherfressend wie früher' kann ich mir gar nicht vorstellen)
dann muss sich das Verhältnis ja irgendwie geändert haben..

aber ich bin nur spitzfindig, nicht so ernst nehmen

 

[Wildcard]

Erinnert sich noch jemand an das alte "Quake I" von idSoftware? Ja? Das (die Engine) wurde mittlerweile in Java implementiert. Man muss dazu sagen dass die Grafik nach wie vor native umgesetzt ist da Java hier keinen direkten Zugriff hat.
Und dazu gibt es auch Benchmarks:
http://bytonic.de/html/benchmarks.html

Das ist nicht Quake, sondern Quake II, aber wie kommst du auf 'Man muss dazu sagen dass die Grafik nach wie vor native umgesetzt ist da Java hier keinen direkten Zugriff hat.'? Das ist auf jogl aufgesetzt.

 

[thE_29]

Also das C Programme langsamer waren hat sicher nix mitn C Compiler zum tun

Vielleicht ein bisi was aber nicht soviel wie unter Java!

Unter C muss man die ganze Speicherpolitik selber machen und von daher, hilft einem da der Compiler nicht soviel an Zeitersparnis..

Daher ist bei den meisten C Programmen zu sagen, sie sind mit der PC Leistung schneller geworden und nicht weil bessere Compiler zum Einsatz kommen!

Und was mich (auch noch unter 1.5) stört ist das beim ersten mal starten bei einer Java Anwendung eben extremst viel Zeit drauf geht.. Vielleicht isses unter 1.6 besser, habe ich aber noch nicht getestet!

Und das Java langsam ist, ist auch ein Hauptproblem von den Programmieren.. Macht man "Rechenintensive" Aufgaben oder gar Aufgaben die sleeps, etc haben in einem ActionListener ohne einen neuen Thread aufzumachen so ist der User schuld.
Dadurch das man hier den EventDispatcher Thread blockiert wird nix neu gezeichnet und daher scheint das ganze "langsamer" zu sein als was anderes...
AlArenal hat mal eine Klasse/Projekt gepostet welches solche Probleme leichter beheben lässt..
Man kann auch dort immer einen Thread anwerfen um es zu umgehen, aber das ist eine andere Geschichte!

 

[AlArenal]

Die Startup-Time bei 1.6 hat schon merklich zugelegt, so mein subjektiver Eindruck. Alles in Allem ist er aber immernoch zäh und je nach Anwendungsbereich ist das etwas nervig, weil man immer in Rechtfertigungszwänge kommt, weil es beispielsweise in Flash so schnell geht, oder selbst (oder gerade) in Squeak (welches als Smalltalk-Ableger ja auch mit einer VM arbeitet).

Man muss wirklich festhalten, dass ohne sich mit vielen Detials in Java rumzuschlagen und das eien oder andere Projekt in Ausgenschein zu nehmen, man sehr schnell sehr unperformanten wirkenden Code liefern kann, da der Eindruck von Langsamkeit oder grafischen Oberfläche schnell mal entsteht, wenn irgendwo irgendwas ins Stocken gerät.

Hier hat man versäumt frühzeitig ein Standard-Framework mitzuliefern, das einen ein wenig an die Hand nimmt und einen führt. Sher anfängerfreundlich ist Java da wirklich nicht, aber das ist ein Problem der gefühlten Performance, nicht derjenigen zu der Java an sich imstande ist.

 

[Lim_Dul]

Das mittlerweile die echten Unterschiede zwischen java/c/c++ deutlich geringer geworden sind, liegt meines Erachtens auch daran, dass die Rechner schneller geworden sind und die Prozessoren komplexer..

Früher hat die Schicht ByteCode zu Maschinencode "interpretieren" von der VM prozentual mehr Performance gekostet, als mittlerweile. Oder anders formuliert: Selbst wenn in C eine Operation A durch das Maschinennähere Modell nur halb soviel Zeit kostet wie in Java, ist mittlerweile die Größe der Einheit A so klein, dass das nicht mehr auffällt. Ob eine Operation nun 2ms oder 1ms braucht, ist nicht meßbar, Ob sie aber 1000ms oder 500ms braucht fällt auf. Das macht sich dadurch bemerkbar, dass die meisten Desktop Anwendungen einen Großteil der Zeit damit verbringen zu warten, dass der User was macht.

Das bedeutet, dass mittlerweile mehr die vernünftige Architektur und die Wahl von guten Algorithmen im Vordergrund steht und nicht mehr die echte Prozessorlaufzeit eines Befehls.

Das Java als langsam gilt hat meines Erachtens aber auch damit zu tun, dass die erste Java-GUI Anwendung die man schreibt langsam ist, da man alles im EDT macht.

Eine bessere Lösung habe ich zwar auch nicht auf die schnelle parat, aber in diese Stolperfalle fällt glaub ich jeder mindestens 1x am Anfang rein. Und das führt dazu, dass es viele Java-GUI Anwendungen gibt, die sich zäh anfüllen.

 

[AlArenal]

Eine bessere Lösung habe ich zwar auch nicht auf die schnelle parat, (...)

Ich schon, den näselnden Ben Galbraith und Foxtrot: http://www.javalobby.org/eps/galbraith-swing-2/

 

[Illuvatar]

Das ist bei mir nur ne graue Fläche, im Opera und im IE7.