[Perfromance Benchmark] Java - C++

Shade Of Mine

Korbinian schrieb:

vc7 pumpt halt einfach mal alle namen in den speicher, da ist ein zugriff natürlich schnell

und trotzdem quasi kein speicher verbrauch!

hatte zwar nie probleme mit intellisense, aber dank VisualAssist brauch ich es auch nicht

muss mir irgendwann mal die neue Version kaufen, es wird ja immer geiler

die einzige Java basierende IDE die ich wirklich verwende ist ZendStudio (seit 2.0). da merkt man, dass Java merklich schneller wird - dennoch ist ZendStudio 4 wesentlich lahmer als VC7 (kann aber nur einen Bruchteil).

Vorallem das Starten ist viel zu lahm Bei diesen kleinen Benchmarks fällt es vermutlich nicht ins Gewicht, aber wenn erstmal ein paar MB Code gejittet werden müssen, dann wirds lahm. zB habe ich .php Dateien nicht mit ZendStudio verknüpft, weil wenn ich mir den Code nur mal kurz ansehen will ist die Startzeit von ZendStudio zu lang.

Beim VC7 hingegen habe ich da keine Probleme...

und ZendStudio ist nicht Pluginbasiert

Marc++us

Ok, dann nehme ich Suns "Java Studio" als weiteres Beispiel für eine quälend langsame IDE.

Marc++us schrieb:

Ok, dann nehme ich Suns "Java Studio" als weiteres Beispiel für eine quälend langsame IDE.

Java IDE's haben auch idr. eine andere Architektur, weshalb die Vergleiche hinken.

Aber Java wird nicht so schnell sein wie c++. Bei solchen winzigen Programmen läßt sich keine vernüftige Aussage treffen.

Java hat eine ganz andere Stärke, die weder Perfromance noch Plattformunabhängigkeit ist.

Java ist die Sprache der Wahl der für verteilte Systeme und Webservices. Nicht zuletzt da die Großen in dieser Branche alles auf Java setzen. Die großen Unternehmen in der Welt setzen nun mal immer mehr auf mehrschichtige Architekturen. Da ist für c++ der leider Zug abgefahren. Die Gründe sind zum einem ein unzulänglicher Standard und zum anderen fehlen IT-Größen die es Pushen. IBM/SAP setzen auf Java, MS auf .NET. Da bleibt auf Dauer für iso c++ nichts mehr übrig.

@toaster:

Da der KDE jetzt auf Windows portiert wird und Qt auch für Windows unter der GPL steht, dürfte c++ noch einmal einen Stoß geben.

Diese Vergleiche gab es früher genauso mit PHP. PHP ist zu langsam hier, PHP ist zu langsam da und was ist heute daraus geworden?

dEUs

An Java-Programmen habe ich bisher ZendStudio und Borlands TogetherSolo benutzt.
ZendStudio ist lahm, Together ist schrecklich. Da ist einfach alles lahm. Der Hammer. So etwas hab ich bisher wirklich nur bei Java-Programmen gesehen, noch nciht bei einem C++-Programm.
Ich bin eindeutig kein Fan von Javabasierten Programmen.
Noch was zu diesem Thema: Auf der Homepage des JCreators (IDE für Java) steht irgendwo sinngemäß: Sie haben Java nicht für die IDE verwendet, weil es einfach zu lahm war.
Wer ständig behauptet, das liegt nicht an Java, sondern an der Architektur, der mag sich meiner Meinung nach die Wahrheit nicht so wirklich eingestehen: Wenn es die Architektur einem so viel schwieriger macht performante Programme zu schreiben, obwohl es (anscheinend) mit der Sprache an sich durchaus möglich wär, dann ist das trotzdem die Schuld der Sprache. In diesem Fall eben der schlechten Architektur.

Ne. Allein der Unterschied Eclipse 3.1M4 <-> 3.0 sagt mir wirklich alles.
Und Netbeans hat auch keine schlechte Performance. Ich verstehe auch gar nicht, wie ihr dazu kommt, IDEs zu vergleichen.
Java IDEs haben Sachen, von denen andere IDEs nur träumen können. Es gibt für keine Programmiersprache so gute IDEs wie für Java. Das ist das absolute Paradebeispiel für "mein Apfel ist schneller als deine Birne".

Marc++us

Optimizer schrieb:

Ich verstehe auch gar nicht, wie ihr dazu kommt, IDEs zu vergleichen.

Naja, wir versuchen halt reale Anwendungen zu vergleichen, und da bietet es sich für Softwerker eben an, ihre reale Anwendung "IDE" zu vergleichen. Und ich kenne keine Java-Excel... sonst hätte ich das genommen.

Optimizer schrieb:

Java IDEs haben Sachen, von denen andere IDEs nur träumen können.

Und das wäre? Z.B. Eingabe von Zeichen ohne Latenzzeit?

Ich verstehe weder das Featureargument, noch das Architekturargument. Wieso dauert das Syntaxcoloring bei einer Java-IDE beim Neuzeichnen, wieso scrollt das Ding so lahm, und warum dauert die automatische Codeergänzung solange? Durch eine Plugin-Schnittstelle wird sowas doch nicht langsamer... während ich tippe, ist doch außer der Tippse nix wirklich aktiv.

Und Together wurde bereits als Beispiel genannt, das Ding ist doch unbrauchbar... wenn das Rendering von Grafiken so lange dauert, dann ist was faul.

Ich weiß ja, daß in dem ganzen Servlet-Bereichen die Java-Anwendungen sich durchgesetzt haben und flott sind, aber bei den größeren Anwendungspaketen mit GUIs bin ich nicht überzeugt.

Ich verstehe weder das Featureargument, noch das Architekturargument. Wieso dauert das Syntaxcoloring bei einer Java-IDE beim Neuzeichnen, wieso scrollt das Ding so lahm, und warum dauert die automatische Codeergänzung solange?

Sorry, aber das ist halt bei mir einfach nicht so, falls sich das auf Eclipse bezieht. Für Netbeans kann ich auch sprechen. Sonst hab ich mir wohl zu wenig Java-IDEs angeschaut.

während ich tippe, ist doch außer der Tippse nix wirklich aktiv.

Das stimmt zwar zumindest bei Eclipse nicht (/me Plugin-Schreiber), aber ist trotzdem auch kein Problem. Wie gesagt, ich kann das in dem Maße wie du das beschreibst nicht nachvollziehen.
Die einzige IDE, die ich kenne und mit dem Syntaxcoloring nicht hinterherkommt ist die Visual C# 2005 Express Beta. Wenn ich da ne Datei öffne, ist sie erstmal 10sec nicht gecolort.
Hast du ne Java 5.0 VM? Zumindest 1.3 ist wirklich noch sehr langsam.

Und Together wurde bereits als Beispiel genannt, das Ding ist doch unbrauchbar... wenn das Rendering von Grafiken so lange dauert, dann ist was faul.

Ok. Kenne ich nicht. Trotzdem, woher kannst du wissen, dass es an Java liegt?

Und ich kenne keine Java-Excel... sonst hätte ich das genommen.

OpenOffice ist AFAIK zu einigen Teilen in Java geschrieben, ich kann aber jetzt nicht sagen, welche Teile.

dEUs

Optimizer schrieb:

Und Together wurde bereits als Beispiel genannt, das Ding ist doch unbrauchbar... wenn das Rendering von Grafiken so lange dauert, dann ist was faul.

Ok. Kenne ich nicht. Trotzdem, woher kannst du wissen, dass es an Java liegt?

Woran sonst?

Ponto

Power Off schrieb:

Nur zu dem geposteten C++ Benchmark:

Der Entwickler dieses Codes hat nicht die geringste Ahnung von der STL.

Der Code muesste naemlich so aussehen:
string s;
for ( int i=0; i < n; ++i ) {
   s += "Hallo\n";
}

Diese Schleife dauert bei mir 5.5 Sekunden. Aber man kann ja was machen.

Ich würde behaupten, folgendes sei schneller:

string s;
string hallo("Hallo\n");
for ( int i=0; i < n; ++i ) {
   s += hallo;
}

Das dauert nur noch 4.5 Sekunden. Aber die ganzen Stringfunktionen machen bestimmt viel zu viele Checks. Das kann man doch direkter, wir wissen ja was wir wollen:

char hallo[] = "Hallo\n";
int const size = strlen(hallo);
string s(size * n, 0);
std::string::iterator iter = s.begin();
for ( int i=0; i != n; ++i ) {
   for (int j = 0; j != size; ++j) {
      *iter = hallo[j];
      ++iter;
   }
}

Und siehe da, das Programm benötigt nur noch 0.4 Sekunden.
Was kann man daran sehen:

1. In C++ gibt es viele Wege das gleiche Ergebnis zu erreichen. Wahrscheinlich gilt das auch für Java.

2. So ein Benchmark kann nicht viel aussagen. Ziel der Messung war wahrscheinlich die Geschwindigkeit von String appends, weshalb die letzte Transformation nicht akzeptabel wäre. Der Programmierer will aber ein Ergebnis erreichen. Mal will er schnell zum Ergebnis kommen, mal will er ein schnelles Ergebnis haben. Sollte jemals eine solche Schleife in einem realen Programm notwendig sein, kann sie je nach Ziel des Programmierers so einfach, wie im ersten Fall oder so kompliziert wie im letzten Fall aussehen. Über beide Fälle sagt der Benchmark jedoch nichts aus, da er etwas misst, dessen Geschwindigkeit völlig unerheblich ist. Denn ist die Geschwindigkeit an dieser Stelle das Nadelöhr, fällt dem Programmierer schnell etwas besseres ein.

dEUs schrieb:

Optimizer schrieb:

Und Together wurde bereits als Beispiel genannt, das Ding ist doch unbrauchbar... wenn das Rendering von Grafiken so lange dauert, dann ist was faul.

Ok. Kenne ich nicht. Trotzdem, woher kannst du wissen, dass es an Java liegt?

Woran sonst?

Ist es jetzt völlig ausgeschlossen, dass es einfach schlecht programmiert ist?

dEUs schrieb:

Optimizer schrieb:

Und Together wurde bereits als Beispiel genannt, das Ding ist doch unbrauchbar... wenn das Rendering von Grafiken so lange dauert, dann ist was faul.

Ok. Kenne ich nicht. Trotzdem, woher kannst du wissen, dass es an Java liegt?

Woran sonst?

Woran liegt es das C/C++ Anwendungen Bufferoverflows haben? Natürlich an C++

Welche VM benutzt ihr? Die 1.4.2 und erst recht die 1.5 sind _viel_ schneller als zum Bleistift die 1.3. Ich rede nur von Sun VM's!

Wie schon erwähnt hat Java auch weniger das Ziel auf dem Desktop als vielmehr auf dem Server. Da ist es dank AS und EJB sehr schnell!

Sovok

Optimizer schrieb:

dEUs schrieb:

Optimizer schrieb:

Und Together wurde bereits als Beispiel genannt, das Ding ist doch unbrauchbar... wenn das Rendering von Grafiken so lange dauert, dann ist was faul.

Ok. Kenne ich nicht. Trotzdem, woher kannst du wissen, dass es an Java liegt?

Woran sonst?

Ist es jetzt völlig ausgeschlossen, dass es einfach schlecht programmiert ist?

dass java desktop-anwendungen in dem ruf stehn träge zu sein is auch ned ganz von der hand zu weisen

dEUs

Optimizer schrieb:

dEUs schrieb:

Optimizer schrieb:

Und Together wurde bereits als Beispiel genannt, das Ding ist doch unbrauchbar... wenn das Rendering von Grafiken so lange dauert, dann ist was faul.

Ok. Kenne ich nicht. Trotzdem, woher kannst du wissen, dass es an Java liegt?

Woran sonst?

Ist es jetzt völlig ausgeschlossen, dass es einfach schlecht programmiert ist?

Können alle Javaprogrammierer jetzt plötzlich nciht mehr programmieren?

Was ich damit sagen will:
Ich finde es doch recht seltsam, dass alle Applikationen, die bei mir so ultralahm waren, bisher alle in Java geschrieben waren. Du willst doch nicht den ganzen Entwicklern einfach Versagen vorwerfen?

Ich finde eure Argumentation so klein-klein. Es liegt an der Architektur, an diesem und jenem, aber um Gottes Willen nicht, kein Stück, an Java.

Entwickler schrieb:

Woran liegt es das C/C++ Anwendungen Bufferoverflows haben? Natürlich an C++

In der Tat liegt das ein stückweit an C++, da es dem Entwickler die Möglichkeit gibt, Bufferoverflows einfach zu produzieren. Genau so scheint es mir mit Java zu sein: Es gibt dem Programmierer die Möglichkeit, einfach lahme Anwendungen zu schreiben.

JCreator is written entirely in C++, which makes it fast and efficient compared to the Java based editors/IDE's.

dEUs

richtiges zitat schrieb:

JCreator is written entirely in C++, which makes it fast and efficient compared to the Java based editors/IDE's.

Danke für's raussuchen, ich meinte aber ein anderes:

<a href= schrieb:

http://www.jcreator.com/faq.htm#52">
Will JCreator be released for other platforms? Will there be a Java version?

The very first version (0.1) of JCreator was a Java version, but we switched to C++, because of performance issues.

Ist natürlich in der Grundaussage das gleiche.

ich arbeite seit eine weile mit jedit, syntaxcoloring usw. ich kann aber echt nicht sagen das es langsamm leuft, ab und zu bekommt man ein graue wand zu sehen bevor es sich aufbaut, aber das sind immer nur bruchteile von sekunden, bei nativen-guis ist die verzögerung auch nicht kleiner nur das man sie nicht sieht

ahja ich konnte aber keine unterschied zwischen 1.42 und 1.5 jvm feststellen

Sovok

gerard2 schrieb:

bei nativen-guis ist die verzögerung auch nicht kleiner nur das man sie nicht sieht

aha...

dEUs

gerard2 schrieb:

bei nativen-guis ist die verzögerung auch nicht kleiner nur das man sie nicht sieht

Hä?
Magst du mir das erklären?

ich kann dir nur von meinen system berichten, aber wenn ich in ein explorer switche sehe ich zwar kein graue wand aber die sysmbolleiten flakern kurz auf und das fenster was vorher im vordergrund war verschwindet erst auch aus der mitte des neuen fenster, auf meinen system ist jedit nicht viel langsammer oder zumindestenz nicht langsammer das es für mich von nachteil wäre gegen über nativen guis, nur das bei jedit ne graue wand zu sehen ist
außerdem wenn man z.b. der javavm eine andere preorität verpasst dann wird das auch noch schneller, ich möche gene mal wissen mit welcher preorität die native-gui gezeichnet wird

@dEUs: Ich gebe absolut recht! Java/Swing ist im Vergleich mit C++/Qt nicht vergleichbar. Habe ich auch nirgends behauptet. Ich sage nur, daß es nicht mehr so ist wie früher.

Die Zukunft in der Wirtschaft(nicht typische Desktopanwendungen!) scheint aber der Thin-Client zu werden. Das sieht man auch an den Stellenangeboten für Java wo häufig J2EE gefordert wird.

Ich persönlich kenne auch keine Multi-Tier Architektur für C++ die irgendwo namenhaft Verwendung findet. Aber vielleicht könnt ihr mir helfen.

Auch im Zusammenhang mit EAI, Webservices und co. höre ich immer nur J2EE.