# [OT] Java langsam? Plattformunabhängigkeit versus Perfomanz

## TheSmallOne

-–- gelöscht -–-Last edited by TheSmallOne on Tue Dec 25, 2012 10:40 pm; edited 1 time in total

----------

## c07

Java ist aber auch nur so eine uniforme Zwischenplattform, die sich noch dazu überhaupt nicht um native Systemkonventionen schert und außerdem grobe Performanceprobleme hat. Wenn es besser implementiert wär (bezüglich GUI), wär es eine Lösung für Applikationen, die übers Netz geliefert werden, aber für lokale Anwendungen ist es sowieso höchstens als Notlösung geeignet.

----------

## TheSmallOne

-–- gelöscht -–-Last edited by TheSmallOne on Tue Dec 25, 2012 10:40 pm; edited 1 time in total

----------

## c07

 *TheSmallOne wrote:*   

> In fast allen Fällen ist Java mindestens genausoschnell, wie ein fertig kompiliertes C-Programm.

 

Wenn es gleich gut programmiert ist, ist das rein prinzipiell unmöglich. Irgendwann muss die Übersetzung ja passieren und auch abgesehn davon ist Java eher mit C++ vergleichbar. Konkret sind es vor allem die Startzeiten (der Rest ist besser geworden). Batik braucht bei mir z.B. über 18 Sekunden und warm immer noch 15. Selbst Mozilla schafft es bei mir in 6¾ bzw. 2½ Sekunden. Bei kleinen Programmen ist das relative Missverhältnis noch größer.

 *TheSmallOne wrote:*   

> Und die GUI ist doch auch nicht wirklich schlecht...

 

Ob es gut oder schlecht ist, ist eher Geschmackssache, aber jedenfalls ist es eine reine VM (die sich gar nicht erst zu tarnen versucht) und als solche immer ein Fremdkörper. Wie es für den Programmierer ausschaut, ist eine ganz andere Frage. Als solcher muss man sich immer mit dem System, für das man programmiert, auseinandersetzen.

----------

## McPringle

 *c07 wrote:*   

> grobe Performanceprobleme

 

Wie kommst Du da drauf, dass Java grobe Performanceprobleme hat? Das war bei alten Versionen bis 1.2 der Fall, vereinzelt auch noch bei 1.3. Aktuellere Versionen weisen - wenn man programmieren kann - keine Performanceprobleme auf. Gerade als Gentoo-Anwender sollte man Parallelen zu Java ziehen koennen, schliesslich gibt es auch positive Gemeinsamkeiten.

McPringle

----------

## c07

 *McPringle wrote:*   

> Wie kommst Du da drauf, dass Java grobe Performanceprobleme hat?

 

Das Design ist halt grundsätzlich nicht auf optimale Performance ausgelegt. Du brauchst ja nur ein Java-Hello-World mit einem C-Hello-World vergleichen (Java ist bei mir um den Faktor 100 langsamer).

kil: Wenn du den Aufruf direkt aus X machst, hast du da sicher noch den alten PATH. Also X erst von einer frischen Shell aus starten (oder in der alten ein ". /etc/profile" machen).

----------

## TheSmallOne

-–- gelöscht -–-Last edited by TheSmallOne on Tue Dec 25, 2012 10:41 pm; edited 1 time in total

----------

## c07

 *TheSmallOne wrote:*   

> Das "Problem" hierbei ist lediglich, dass erstmal die JVM geladen werden muß, das dauert natürlich ein bißchen länger, vorallem bei Programmen, deren C-Pendants kaum irgendwelche Libraries benutzen.

 

Die Sachen waren natürlich alle im Speicher. Es geht hier also nur noch um die Initialisierung. Aber auch bei der Arbeit ist Java langsamer. Bei einem 

```
for ( i= 0; i < 1000000000; ++i ) j= i;
```

 braucht es z.B. 3 mal so lang wie ein optimiertes C-Programm. Nur im Verhältnis zu -O0 ist es schneller.

----------

## PrakashP

 *Quote:*   

> 
> 
> Davon abgesehen sollten gerade wir Linuxuser, nicht wirklich so Performancehungrig sein... schließlich basiert ein großteil des Systems auf reinen Shellskripten (man denke nur mal an die ganze Init-Prozedur), und interpretierte Skripte sind ja nun wirklich das performancelastigste, das möglich ist. 
> 
> 

 

Abgesehen, daß es mit Linux (dem kernel) wenig zu tun hat, kotzt es mich persönlich an, daß Leute Skript-Sprachen als "richtige" Programmiersprache einsetzen. Ich denke da vor allem an portage, was gähnend langsam ist - so sehr mir auch der Leistungsumfang gefällt. Auch die ganze Boot Prozedur ist doch von vorgestern.

Mit Java kann ich mich auch ncith wirklich anfreunden. Für Standardinge ganz nett. Aber ich möchte mal SIMD Programmierung in Java sehen.  :Razz: 

----------

## ZX-81

 *c07 wrote:*   

> Aber auch bei der Arbeit ist Java langsamer. Bei einem 
> 
> ```
> for ( i= 0; i < 1000000000; ++i ) j= i;
> ```
> ...

 

Eine Leerschleife, die nichts sinnvolles macht für einen Benchmark zu verwenden ist nicht sinnvoll. Der Optimizer könnte z.B. erkennen, dass die Schleife mit 

```

i=1000000000

j=i-1;

```

ersetzt werden könnte. 

Ich verwende für solche Test immer das "Sieb des Erathostenes". 

```

class Sieve

{

   public static void main(String[]argv)

   {

      int LIMIT = 100000000;

      boolean[] prime = new boolean[LIMIT];

      for(int i=2;i<LIMIT;i++)

         prime[i]=true;

      long t1 = System.currentTimeMillis();

      for(int i=2; i<LIMIT; i++)

         if(prime[i])

            for(int k=i+i; k<LIMIT; k+=i)

               prime[k]=false;

      long t2 = System.currentTimeMillis();

      //for(int i=2;i<LIMIT;i++)

      //   if(prime[i])

      //      System.out.print(i);

      System.out.println();

      System.out.println(t2-t1);

   }

}

```

Das ist mit den Zugriffen auf das boolsche Array ein Killer für jeden Interpreter und jede ineffiziente virtual Machine. 

Die ersten Javaversionen waren hier um Faktor 40 langsamer als C. 

Inzwischen ist kein nennenswerter Unterschied mehr auszumachen. 

Interessant finde ich auch, dass das Programm unter der Blackdown-JVM sogar etwas schneller läuft als mit gcj nativ compiliert.I

----------

## return13

ihr wollt mir doch nicht weiss machen das man Java und C/C++ auf die selbe Schiene legen kann!

Es ist doch was vollkommen anderes wenn die Software erst zur laufzeit intrepretiert wird, als

ein Binäres Programm zu haben das direkt an den Prozessor weitergereicht werden kann - oder nicht?

Mein Beispiel:

Zeigt mir ein Betriebssystem das mit Java Programmiert wurde...

Sicherlich hat Java mit den Jahren an geschwindigkeit zugelegt, aber ich würd trotzdem nicht auf die Idee kommen es

mit C/C++ zu vergleichen:

Noch gibt es kein Microcontroler den man mit Java ansprechen kann oder?

Ich finde alle Programmiersprachen haben ihre Vor- und Nachteile, genauso wie es auch Vor- und Nachteile von Java gibt,

für mich stellt es eine gute alternative da, um meine Software leichter verbreiten zu können...

----------

## _hephaistos_

bin absolut der gleichen meinung!

java IST einfach langsamer!

hab hier limewire und tvbrowser laufen. egal ob ich nun das programm im vordergrund habe oder nicht -> es ist immer ca. auf 6-10% CPU!

java mit c/c++ programmen bezügl. der effizienz zu vergleichen ist einfach naivität... ev. leute, die kein c/c++ lernen wollen und daher einfach behaupten, dass java eh das gleiche kann  :Rolling Eyes: 

nichts für ungut  :Smile: 

cheers

----------

## moe

Java wird doch nicht zur Laufzeit interpretiert?

Aber ich stimme dir zu, der Vergleich hinkt. Sinnvoller wäre ein Vergleich mit einer Sprache die ebenfalls in einer VM läuft.

Aber ich finde trotzdem, dass Java nich der Weisheit letzter Schluss ist.. Wenn mir unter Linux mal ein Programm abschmiert, dann wars meist ein Java-Programm (z.B. sancho, oder Mozilla aufgrund irendeines applets, Opera genauso)

Da ja hier soviele Java-Befürworter sind, müssen diese Probleme ja eher ein Einzelfall sein?

Gruss Maurice

----------

## sven-tek

weiss jemand ob die java vm überhaupt mmx und isse register benutzt?

Ich vermute ja mal nicht, schon das wäre ja ein Hinderniss das java wirklich schnell wird.

Ausserdem hat Java schreckliche GUI's. Ich hasse swing und awt, das sieht doch einfach nur hässlich aus und auch vom benutzen her ist das einfach nicht schnell genug.

----------

## return13

 *moe wrote:*   

> Wenn mir unter Linux mal ein Programm abschmiert, dann wars meist ein Java-Programm (z.B. sancho, oder Mozilla aufgrund irendeines applets, Opera genauso)
> 
> Da ja hier soviele Java-Befürworter sind, müssen diese Probleme ja eher ein Einzelfall sein?
> 
> Gruss Maurice

 

Stimme da voll und ganz zu... meistens hab ich die probleme mit Java Programmen, z.B. azureus, das sich irgendwie nicht vollständig schliessen kann und trotzdem im hintergrund mitlaufen will und ichs deswegen so einstellen musst das es in nem xterm gestartet wird, damit ichs dann auch vernünftig beenden kann...

----------

## ZX-81

 *hephaistos6 wrote:*   

> 
> 
> java mit c/c++ programmen bezügl. der effizienz zu vergleichen ist einfach naivität... ev. leute, die kein c/c++ lernen wollen und daher einfach behaupten, dass java eh das gleiche kann 
> 
> 

 

Da triffst Du jetzt aber den Falschen. Ich war seit mehr als 10 Jahren in verschiedenen grossen Softwareprojekten als C++ Entwickler tätig  (leider vorwiegend unter Windows  :Embarassed:  ) und arbeite erst seit zwei Jahren in einem Java Projekt. 

Gerade weil ich die Nachteile von C++ kenne bin ich sehr von Java angetan. Mein letzte Projekt wäre in dem vorgegeben Zeit und Budgetrahmen mit C++ nicht realisierbar gewesen.

Klar hat Java auch Nachteile, dieses "Java ist langsam wegen VM" ist aber grösstenteils nicht wahr.

Der subjektive Eindruck "Java ist langsam" kommt wohl teilweise von Swing. Das ist schon ein ganz schön grosses (plattformunabhängiges) GUI-Monster. Zudem scheint die X-Implementierung recht ineffizient zu sein. Netbeans (auf Swing basierende Java-IDE) war die einzige Anwendung mit der ich nicht auf einem per wlan angebundenen X-Terminal  (=Notebook) arbeiten konnte (wegen Performance, Das ist aber schon Jahre her, könnte inzwischen auch besser sein). Mit Eclipse (nicht auf Swing basierende Java-IDE) ist das kein Problem.

Übrigens plagen wir uns bei gentoo mit dem Problem "C ist langsam" herum. Nach meinen Erfahrungen können Java Programme bis zu 100 mal schneller übersetzt werden als C Programme. Mit Java würden die Emerge-Zeiten im Minuten statt im Stunden Bereich liegen.

auch nichts für ungut  :Very Happy: 

ZX

----------

## SinoTech

Also ...

1. JAVA ist zwar langsamer als ein in C/C++ geschriebenes Programm, aber bei vielen Anwendungen kommt es darauf nicht an

2. Kann in JAVA Programmen auch C/C++ Code genutzt werden (Beispielsweise über das laden von Shared Libraries) der dann nicht von der JVM interpretiert wird (wodurch es auch möglich ist schnellen Code zu erzeugen)

3. Ich hatte noch keine Probleme mit JAVA.

Mfg

Sino

----------

## pablo_supertux

 *moe wrote:*   

> 
> 
> Aber ich finde trotzdem, dass Java nich der Weisheit letzter Schluss ist.. Wenn mir unter Linux mal ein Programm abschmiert, dann wars meist ein Java-Programm (z.B. sancho, oder Mozilla aufgrund irendeines applets, Opera genauso)
> 
> Da ja hier soviele Java-Befürworter sind, müssen diese Probleme ja eher ein Einzelfall sein?
> ...

 

genau, mein Opera stürtzt immer ab, wenn eine Seite ein Java applet hat, der einen Fehler hat, und selbst Applets ohne Fehler zerstören mein Opera, muss immer Opera neu starten, und ich bin uaf meine Software der Uni angewiesen, die nur in Java verfügbar ist, und optimal läuft das Zeug nicht, frisst viel und bleibt eher sowieso immer stehen...

An sich finde ich die Idee und Initiative von Java (und ich glaube .NET macht etwas ähnliches, oder? ) nicht schlecht, aber ich glaube, dass Java eher Vorteile in der Softwarebranche bringt, wenn man Close source Software verkauft, so programmiert man einfach einmal und die VM kümmert sich um die nicht immer anwessende Portabilität. Aber für Open Source Projekte finde ich das schlecht, denn man kann mit C/C++ auch eine gewiese Portabiltät erreichen, siehe OpSrc Projekte wie Gnome oder KDE, die mit GNU oder BSD oder Solaris laufen ohne dass es eine "VM" á la Java VM geben muss.

Aber was mich wirklich an Java Programme nervt, mehr nerven mich die Entwickler, ist dass sie trozt Java schaffen, Programme zu schreiben, die nur unter Windows gut laufen bzw. überhupt laufen. Ich hab benutze ein Java Programm, das meine Uni für die Aufzeichnungen der Vorlesung benutzt, und machne haben sogar Video mit dem Dozenten drauf, wo man sieht, wie er die Vorlesung hält, usw. Ich musste einmal die Vorlesung verpassen und dann zu Hause wollte ich mir die Vorlesung anschauen und das Programm konnte kein Video anzeigen, Fehlermeldung: Windows Media Libs not found.  :Evil or Very Mad:  von wegen Systemunabhängigkeit. Gut, ohne Video geht auch, schließlich sind die Folien wichtiger, trotzdem finde ich immer leere Kästchen an der Stelle von den ä,ö,ü,ß, Sonderzeichen, usw, die Texte sind verrutsch, warum? Weil dieses sch$§&%# Programm keine Windows Fonts oder sowas in der Art findet... und das finde einfach nervig.

----------

## PrakashP

Ein Grund warum Java bei Standardalgortihmen fast so schnell wie C abläuft liegt am vollkommen anderen Speichermanagement. Soweit ich es verstanden habe, gibt es bei Java keine strikte Aufteilung von Daten und Programmspeicher, im Gegnteil Java überschreibt den Programmspeicher dynamisch um mehr Performanz herauszuholen. Dies macht die ganze Sache relativ unsicher. (Nix mit NX...) Die aktuellen bk kernels bieten daher einen geschützten Bereich an, worin bytecode ausgeführt werden kann.

Ich finde es schon erstaunlich, wieviel Java aus JIT herausholt, nur benutzt es Dinge, die mit C einfach nicht erlaubt sind.

----------

## TheSmallOne

-–- gelöscht -–-Last edited by TheSmallOne on Tue Dec 25, 2012 10:42 pm; edited 1 time in total

----------

## petter_r

 *PrakashP wrote:*   

> Ein Grund warum Java bei Standardalgortihmen fast so schnell wie C abläuft liegt am vollkommen anderen Speichermanagement. Soweit ich es verstanden habe, gibt es bei Java keine strikte Aufteilung von Daten und Programmspeicher, im Gegnteil Java überschreibt den Programmspeicher dynamisch um mehr Performanz herauszuholen. Dies macht die ganze Sache relativ unsicher. (Nix mit NX...) Die aktuellen bk kernels bieten daher einen geschützten Bereich an, worin bytecode ausgeführt werden kann.
> 
> Ich finde es schon erstaunlich, wieviel Java aus JIT herausholt, nur benutzt es Dinge, die mit C einfach nicht erlaubt sind.

 

Hallo!

Ich glaube ich träume, wir reden hier von Java vs C und sagen, dass bei Java mehr Speicherfehler als bei C vorkommen können. In C kan ich in einen String einfach ein längeres Feld schreiben und er schreibt es im Speicher fort. Das selbe bei Arrays. Von der Pointerproblematik möchte ich hier gar nicht mal reden. Was meint Ihr wo die vielen Bufferoverflows herkommen? All das ist in Java nicht möglich. Das natürlich die JVM einen Fehler haben kann ist natürlich wieder möglich, da diese in C++ programmiert ist. Also ein Javaprogrammiere muss sich um Speicherfehler kaum kümmern, was die Entwicklungszeit stark verringert. Um die JVM kümmert sich Sun oder IBM und mittlerweile haben diese einen Reifegrad erreicht, der sehr gut ist.

Das mit Swing ist auch so ein Thema.

Swing war zu seiner Zeit absolut ungewöhnlich vom Modell und deshalb haben es die Programmierer falsch verwendet. Z.b. haben sie im Eventthread nicht nur GUI relevantes gemacht sondern auch die Verarbeitung von Daten. Durch diesen Fehler erscheinen Swing Programme wenig "lebendig" Wenn man aber wie es in Java relevant ist mit Multithreading richtig arbeitet gibt es in auch bei Swing keine Performanceprobleme, mit der Ausnahme das man relativ viel Hauptspeicher benötigt. Ähnliches Problem ist bei Verwendung von QT. Unter Linux war auch lange Zeit ein Problem in Java, dass NPTL nicht unterstützt wurde und deshalb Threads sehr langsam waren. Das ist aber auch jetzt Vergangenheit.

Zum Aussehen des GUI's seht euch einfach mal die Guis auf http://www.jgoodies.com/freeware/jdiskreport/screenshots.html

sehr interessant auch das http://www.jgoodies.com/freeware/metamorphosis/screenshots.html

Sind zwar im Windowsdesign sehen aber auch unter X sehr gut aus.

Grüße

Ralf

----------

## PrakashP

 *Quote:*   

> 
> 
> Also Java ist primär auf Sicherheit und Interoperabilität programmiert. Es ist einem Programm so gut wie unmöglich aus seinem vorgegebenen Sandkasten auszubrechen oder an andere Programme ranzukommen. Wie das ganze dann intern in der JVM geregelt ist, ist somit völlig nebensächlich.
> 
> Nach oben 	
> ...

 

Ich weiß daß Java nach außen hin sicher ist, nur die Art wie der compiler arbeitet ist es nicht. Java versucht dem mit der Sprache entgegenzuwirken, wie der Vorredner es schon richtig ausführte, aber wenn der compiler ein Fehler macht (und es ist utopisch nazunehmen, daß der bugfrei ist), ist es schneller mit Java zuende...wie einige hier schon berichten.

----------

## petter_r

Ein Beispiel aus der Praxis. Ich betreue ein ziemlich großes Webprojekt für unsere Firma, dass komplett in Java (Websphere) geschrieben ist. Hier wird natürlich permanent mit JIT gearbeitet und es ist noch nie. Läuft jetzt seit ca. 2 Jahren zu einem Fehler im Bereich JIT gekommen. Ehrlich gesagt, verwenden wir auch über JNI einen Zugriff auf eine Applikation die ein C++ API zu Verfügung stellt und da kommt es regelmäßig zu fehlen, so dass wir diesen Bereich momentan umstellen mussten.

Also vertrau der JVM mehr. Und ja ich weiß leider sind viele Java Anwendungen ein Riesenschmarren, weil von schlechten Programmierern zusammengestopelt. Aber es gibt auch sehr gute. Wie z.B. Netbeans läuft bei mir auf Windows uns Linux ppc absolut stabil.

Grüße

Ralf

----------

## Ragin

Java ist teilweise wirklich fast so schnell wie C++. Das Problem hierbei ist nur, dass man unterscheiden muss, um was für Programme es sich handelt und wie diese programmiert werden. Es gibt viele Dinge die man nutzen kann, die auch auf den ersten Blick keine Performance kosten, werden diese aber mehr (oder öfter angewendet) kommt dann auch eine beträchtliche Summe an Zeitverlust heraus. Werden diese Performance-Vorzüge nicht generell verwendet, sondern der Code einfach so "runtergerattert" erhält man oft auch langsamere Programme. Diese Optimierungen fangen schon damit an, dass man bei einer for-Schleife, die eine Liste ausliest nicht for ( int i=0; i<liste.size(); i++) ... sondern for (int i=0, size = liste.size(); i<size; i++) ... schreibt. Dadurch wird die Listengröße nur beim Start der Schleife ausgelesen und nicht bei jedem Durchlauf. In einem großen Projekt kommt dann bei vielen ns auch mal einige ms und dann irgendwelche Sekunden als Zeitverlust raus.

Wen solche Optimierungen interessieren kann sich ja mal von Addioson-Wesley das Buch "Performant Java programmieren" (ISBN: 3-8273-2003-8 (evtl. gibts auch schon ne neuere Ausgabe) besorgen.

Und dann spielen natürlich, wie oben erwähnt, Punkte wie swing / awt u.ä. eine tragende Rolle. Auch hier kann man wieder entweder den Code runterrattern oder zusehen, dass man eine klare Struktur erhält und keine übergroßen Module usw. generiert. Man könnte das ganze jetzt noch mit Datenbanklayern usw. durchkauen, was ich euch mal ersparen will  :Smile: .

Fazit: Da Java sehr unterschiedlich programmiert werden kann (ich nenn es mal Normal-/Performancemodus  :Smile: ) und es massenhaft Erweiterungen/Bibliotheken gibt, die das ganze auch noch drücken kann es je nach Programmierer/verwendeten Erweiterungen (hier sollte man sich fragen ob der Zweck erfüllt wird oder die Bibliothek überhaupt benötigt wird) langsamer, aber auch schneller sein und dann annähernd an C++ rankommen, dass es fast vergleichbare Resultate erbringt.

[Edit: Abbruchbedingung geändert  :Smile: ]

----------

## PrakashP

Uhm könntest du  *Quote:*   

>  for (int i=0, size = liste.size(); i++)

  erklären? Ist das was Java spezifischen, denn ich verstehe das nicht...(Abbruchbedingung?) Ich dneke du hast i<size vergessen...aber das ist bei C ja dann auch cniht anders, außer der Compiler ist intelligent genug.

----------

## Teetante

Je nachdem welchen Benchmark man nutzt, ist Java schneller/langsamer/gleichschnell verglichen mit C/C++.

Das Benchmarking in dem Zusammenhang ist leider meist stark gefärbt (schlechter C++ Compiler genommen oder ein Proplem, was man in Java nicht schön lösen kann), darum geben sie meiner Meinung nach nicht besonders viel her.

Was sich gezeigt hat, ist dass Java bei reinen Textmodus anwendungen auf dem Desktop absolut schnell genug ist (nur die Startzeiten sind ein Problem). Das grösste Problem sehe ich in den GUI-Toolkits. AWT und Swing sind (meiner subjektiven Ansicht nach) einfach nicht schnell genug. Andere Sprachen nutzen in diesen Zusammenhägen Links zu kompilierten Bibliotheken, was ich für deutlich sinnvoller halte.

Die Idee Plattformunabhängigkeit durch Einschieben einer Abstraktionsebene zu lösen ist sehr sinnvoll und für Desktop Anwendungen meiner Meinung nach  die Zukunft.  Ob es allerdings die JVM sein wird, die in dieser Hinsicht die Standarts setzen wird muss sich noch zeigen, Java ist halt nicht als Basis für freie Software zu nutzen, das kostet sicherlich einiges an Entwicklern.

Zusammenfassend muss man festhalten: Java ist sicherlich für vieles schnell genug nur der Einsatz der Java-eigenen GUI-Toolkits ist nicht anzuraten, die sind leider unverhältnismässig langsam (Swing und AWT).

----------

## McPringle

 *c07 wrote:*   

>  *McPringle wrote:*   Wie kommst Du da drauf, dass Java grobe Performanceprobleme hat? 
> 
> Das Design ist halt grundsätzlich nicht auf optimale Performance ausgelegt. Du brauchst ja nur ein Java-Hello-World mit einem C-Hello-World vergleichen (Java ist bei mir um den Faktor 100 langsamer).

 

Wer benutzt denn schon ein "Hello World" fuer Benchmarks? *g* Bei meiner taeglichen Arbeit habe ich noch nicht bemerkt, dass Java Performanceprobleme hat. Und ja, ich entwickel damit durchaus als gross zu bezeichnende Anwendungen. Aktuell arbeite ich an einem komplett auf Java basieren ERP-System. Das schafft auf der gleichen Hardware mehr Operationen als das vorher eingesetzte auf C basierende System.

Warum? Einfache Erklaerung: Java kompiliert den Bytecode der VM speziell auf die Hardware, auf der die VM aktuell laeuft, kann also auf diese Weise aus dem gleichen Bytecode immer das Optimum an Geschwindigkeit herausholen. Egal, ob ich es auf einem 386er SX starte oder auf einem Pentium 4 mit HT. Wenn man jedoch ein nativ kompiliertes Programm nimmt, dann ist es immer nur auf eine spezielle Plattform ausgerichtet. Damit ein C-Programm auf einem 386er SX noch laeuft, darf man keine erweiterten Funktionen des Prozessors nutzen.

Ob eine Java-Anwendung gut oder schlecht, langsam oder schnell ist liegt nicht daran, dass sie mit Java entwickelt wurde, sondern sehr, sehr oft am Entwickler bzw. Team und die nicht optimale Nutzung objektorientierten Codes. Das gleiche gilt fuer das Aussehen, die GUI, einer Java-Anwendung. Auch da kann man mit einfachen Mitteln sehr viel erreichen. Ich verweise in solchen Faellen gerne auf JDiskReport: http://www.jgoodies.com/freeware/jdiskreport/ Die Anwendung ist durchaus huebsch anzusehen und sie ist schnell.

Auch lese ich hier im Thread, dass Java oft abstuerzt - ich weiss ja nicht, was Ihr alle macht und wie Ihr euer System konfiguriert habt. Ich setze nur "stable" Software ein (kein ~x86), habe keine agressiven Optimierungen und bei mir laufen Java-Anwendungen in der Regel ueber mehrere Wochen hinweg ohne dass ich sie beende oder dass Abstuerze zu verzeichnen waehren. Dazu gehoeren auch etwas umfangreichere Anwendungen wie beispielsweise Eclipse oder das oben angesprochene ERP-System. Meine Mail-Client Columba (http://columba.sourceforge.net/) habe ich etwa drei Wochen nicht beendet und trotz taeglicher intensiver Nutzung macht er keine Mucken und ist performant. Nur weil hier auf diesem Rechner in den naechsten Tagen Updates anstehen (u.a. auch der Kernel) werde ich die Anwendungen beenden. Sonst - da bin ich ueberzeugt - wuerden sie noch etliche Wochen weiter Ihren Dienst verrichten.

jm2c

McPringle

----------

## Voltago

"Hello World" zu langsam mit Java.... Meine Güte! Also das ist, wie schon McPringle sagte, kein wirklich ernstzunehmender Benchmark-Fall.

Mal ein paar Punkte, die ich hier einfach so in die Diskussion werfen will (wahrscheinlich hat das eh schon jemand gesagt, aber den ganzen Thread will ich nicht durchlesen, da ärgere ich mich bloß):

1. In der Praxis muß selten was so schnell wie möglich laufen, es muß nur schnell genug sein.

2. Java (ausgeführt auf einer VM) hat einige Vorteile gegenüber nativer Software (Speichermanagement, Plattformunabhängigkeit), aber das kostet natürlich (Memory-Footprint, Startzeiten). Ob sich diese Kosten lohnen, hängt a) von der Anwendung und b) von den Anwendern ab.

3. Auch mit großen Swing-Anwendungen läßt sich angenehm arbeiten, probiert doch mal Netbeans 4.x. (Natürlich ist das nicht ganz so "snappy" wie Eclipse oder Visual Studio, stürzt dafür aber auch nicht ständig ab.)

----------

## Ragin

 *PrakashP wrote:*   

>  Ich dneke du hast i<size vergessen...aber das ist bei C ja dann auch cniht anders, außer der Compiler ist intelligent genug.

 

Da denkst du richtig  :Smile: 

Habs auch schon im Beitrag abgeändert  :Smile: .

----------

## ro

Java und Performanceproblem? Das ist definitiv falsch! Java ist der Hammer was Anwendungssoftware betrifft. Das Problem bei Java ist nicht das Performanceproblem an sich, sondern die Implementierung der Java VM. Für einen user mag es lange dauern, bis die Java VM geladen ist, aber wenn es ums berechnen geht gibts (im allgemeinen) nix schnelleres wie Java...da halten nicht einmal "echte" kompilierte Programmiersprachen wie C/C++ mit (Beispiel: Twofish Algorithmus). Toll ist auch, dass es Java Prozessoren für embedded Devices gibt. Im Bereich Web ist Java auch vorne dabei: Java Server Pages sind fast so schnell wie PHP+Perl, und schneller als ASP, und das, obwohl Java eigentlich nicht (wie Perl/PHP) darauf ausgelegt ist, primär mit Texten/Textdateien zu arbeiten. Außerdem ist es leicht zu lernen, ziemlich sicher (man denke nur an Pointers in C!). Nachteil ist halt auch wieder dass man mit dem Linux kernel nicht viel anfangen kann mit java  :Sad: 

----------

## TheSmallOne

-–- gelöscht -–-Last edited by TheSmallOne on Tue Dec 25, 2012 10:43 pm; edited 1 time in total

----------

## Voltago

 *TheSmallOne wrote:*   

> Also es gibt da irgendwie so eine Möglichkeit über Kernel-Support für Misc-binaries automatisch die JVM zu starten, wenn man ein Java-Prog ausführt (also execute-bit gesetzt und dann auf der Kommandozeile einfach den Namen eingegeben).

 

Aber braucht's des? Wrapper scripts sind einfacher und flexibler und der Kernel ist nicht vom Userland-Environment (JAVA_HOME, CLASSPATH, etc...) abhängig.

 *Quote:*   

> Wenn nein: Was spricht dagegen?

 

Dann liefe alle Java-Software mit Kernel-Privilegien. Das spricht dagegen.

----------

## TheSmallOne

-–- gelöscht -–-Last edited by TheSmallOne on Tue Dec 25, 2012 10:44 pm; edited 1 time in total

----------

## Voltago

 *TheSmallOne wrote:*   

> Nein, das was mit Kernelprivilegien läuft ist nur die JVM; die Java-Programme selbst laufen immernoch innerhalb ihrer Sandbox, eingeschränkt durch das, was die Sicherheits-Policys vorgeben...

 

Aber das Java-Prog sollte mit den Rechten des ausführenden Benutzers laufen. Wenn ich das jetzt erst noch im Kernel nach-implementieren muß, wozu hab' ich dann überhaupt das Userland?

Na und aus so einer Sandbox kann man ja auch unter keinen Umständen ausbrechen...  :Wink: 

----------

## SinoTech

 *TheSmallOne wrote:*   

> 
> 
> Nein, das was mit Kernelprivilegien läuft ist nur die JVM; die Java-Programme selbst laufen immernoch innerhalb ihrer Sandbox, eingeschränkt durch das, was die Sicherheits-Policys vorgeben...
> 
> Nur weil man die JVM in den Kernel einbaut muß man nicht gleich alle Sicherheitseinstellungen weglassen. Das scheint mir kein wirkliches Argument gegen eine JVM im Kernel zu sein.

 

Was genau ist denn der Unterschie zwischen einem laufenden Java-Programm und einer aufenden JVM ??? Die JVM ist schliesslich der Teil der den Java code ausführt. Hat also die JVM Rechte so hat sie auch das Java-Programm. Du kannst schliesslich auch kein JAVA programm daran hintern auf das Internet zuzugreifen wenn du der JVM die Rechte gegeben hast (Hatte es mal unter Windows vor einiger Zeit ausprobiert) oder sehe ich da jetzt etwas falsch ?

Mfg

Sino

----------

## ZX-81

 *ro wrote:*   

> Java Server Pages sind fast so schnell wie PHP+Perl

 

Wenn Java Server Pages auch nur annähernd so langsam und resourcenfressend wie PHP wären, wurde ich keine Web-Anwendungen damit entwickeln.

----------

## SinoTech

 *ro wrote:*   

> Java und Performanceproblem? Das ist definitiv falsch! Java ist der Hammer was Anwendungssoftware betrifft. Das Problem bei Java ist nicht das Performanceproblem an sich, sondern die Implementierung der Java VM. Für einen user mag es lange dauern, bis die Java VM geladen ist, aber wenn es ums berechnen geht gibts (im allgemeinen) nix schnelleres wie Java...da halten nicht einmal "echte" kompilierte Programmiersprachen wie C/C++ mit (Beispiel: Twofish Algorithmus).[...]

 

Ok ... also nur das ich das jetzt nicht falsch verstehe.

1. Java ist eine interpretierte Sprache. Heißt das der Byte code in den "class" Dateien von der JVM interpretiert wird

2. Die JVM ist nichts anderes als ein C/C++ Programm das diesen Bytecode versteht und ihn ausführt

3. Wie kommst du darauf das Java schneller sei als jedes C/C++ Programm wenn die JVM selbst nur ein solches ist ?

Mfg

Sino

----------

## TheSmallOne

-–- gelöscht -–-Last edited by TheSmallOne on Tue Dec 25, 2012 10:44 pm; edited 1 time in total

----------

## SinoTech

Was dann aber wiederum doppelten Konfigurtaionsaufwand bedeuten würde weil ja schließlich keine am System gemachten Einstellungen für die JVM gelten würden (Wenn wie weiter oben vorgeschlagen die JVM in den Kernel geschraubt wird). Bsp.:

- Alle Einstellungen an einer FW müssten zusätzlich an der JVM vorgenommen werden da die FW nur die JVM blocken oder durchlassen könnte aber keine einzelnen Javaprogramme (Da der eigentliche Prozess ja die JVM ist und nicht das "class"-file an selbst)

Ausserdem würde der Kernel ziemlich aufgebläht da die JVM mit Sicherheit nicht gerade klein ist.

Und die JVM sollte (logischerweise) möglichst fehlerfrei sein (Und da bin ich mir nicht ganz sicher)

Mfg

Sino

----------

## Carlo

 *petter_r wrote:*   

> Zum Aussehen des GUI's seht euch einfach mal die Guis auf http://www.jgoodies.com/freeware/jdiskreport/screenshots.html
> 
> sehr interessant auch das http://www.jgoodies.com/freeware/metamorphosis/screenshots.html
> 
> Sind zwar im Windowsdesign sehen aber auch unter X sehr gut aus.

 

Abgrundtief häßlich. Ich habe absolut nichts gegen Java, aber Swing ist (solange ich es irgendwie verantworten kann) Ausschlußgrund für eine Anwendung.

----------

## McPringle

 *SinoTech wrote:*   

> 1. Java ist eine interpretierte Sprache. Heißt das der Byte code in den "class" Dateien von der JVM interpretiert wird
> 
> 2. Die JVM ist nichts anderes als ein C/C++ Programm das diesen Bytecode versteht und ihn ausführt
> 
> 3. Wie kommst du darauf das Java schneller sei als jedes C/C++ Programm wenn die JVM selbst nur ein solches ist ?

 

Zu 1: Java ist keine interpretierte Sprache mehr. Schon seit Jahren nicht mehr. Der Java Quellcode wird vom Entwickler in Bytecode compiliert. Dieser Zwischencode wird von der VM vor der Ausfuehrung in nativen Code gewandelt - und zwar, das ist das besondere, unter Beruecksichtigung der aktuellen Gegebenheiten, das bedeutet auch unter Beruecksichtigung der Funktionen der verfuegbaren Prozessoren. Habe ich als User einen P4 nutzt die VM automatisch beim Kompilieren alles, was dieser Prozessor kann.

Zu 2. Siehe auch 1. Bytecode wird nur dann von der VM interpretiert, wenn eine Kompilierung keinen Sinn machen wuerde. Um das festzustellen, laeuft innerhalb der VM ein Analysierungs- und Optimierungsprozess - waehrend der kompletten Laufzeit der Anwendung. Dieser Prozess ist nicht fest sondern "lernt" auch dazu.

Zu 3: Reine Logik. Wenn eine Softwarefirma eine CS-Anwendung vertreibt, soll diese auf moeglichst vielen Rechnern laufen. Nehmen wir als Beispiel eine Windows-Anwendung. Wenn ich als Anwender im Laden eine Software kaufe, erwarte ich, dass sie auch noch auf dem hier neben mir stehenden Windows-PC mit einem Pentium 2 Prozessor laeuft. Genauso wie auf meinem Hauptrechner mit Pentium 4. Der Hersteller kann also beim Kompilieren seines C/C++-Programmes nur den kleinsten gemeinsamen Nenner beruecksichtigen. Da Java hingegen on-the-fly optimiert und in nativen Code kompiliert, ist Java in vielen Bereichen schneller als eine C/C++-Anwendung. Es sei denn, auch die C/C++-Anwendung wird auf genau dieses System hin optimiert, dann waeren sie in etwa gleichwertig. Allerdings hat Java dann immer noch seinen innerhalb der VM laufenden analysierenden und lernfaehigen Optimizer.

McPringle

EDIT: Typo korrigiert...

----------

## McPringle

 *Carlo wrote:*   

> Abgrundtief häßlich.

 

Das ist ja nun wirklich Geschmackssache. Mir gefaellts.

 *Carlo wrote:*   

> Ich habe absolut nichts gegen Java, aber Swing ist (solange ich es irgendwie verantworten kann) Ausschlußgrund für eine Anwendung.

 

Weshalb? Bitte begruende das doch. Denn Swing unterstuetzt das Wechseln des Look-n-Feels (oft "themable" genannt, aber mit diesem nicht vergleichbar, da sehr viel leistungsfaehiger). Mit den verschiedenen Look-n-Feels, die man natuerlich auch selbst erstellen kann, kann man eine auf Swing basierende Anwendung nicht nur komplett verschieden aussehen sondern sich auch komplett verschieden anfuehlen (bedienen) lassen. Man kann Swing sogar das aktuelle GNOME- oder KDE-Theme nutzen lassen. Alles nur eine Frage der Konfiguration und der Freizuegigkeit in der Gestaltung der Anwendung, die einem der Entwickler zugesteht. Die Moeglichkeiten in der Gestaltung der Anwendung sind mit Swing absolut grenzenlos. Das ist ja gerade das Besondere daran.

McPringle

----------

## schachti

 *SinoTech wrote:*   

> 
> 
> 1. Java ist eine interpretierte Sprache. Heißt das der Byte code in den "class" Dateien von der JVM interpretiert wird
> 
> 

 

AFAIK ist das falsch. Gewissermaßen ist Java eine kompilierte Sprache, denn der Quelltext wird in Bytecode kompiliert. Die JVM emuliert eine virtuelle Maschine, auf der der Bytecode läuft.

EDIT: Leider einen Tick zu spät, McPringle hat es ausführlicher und präziser erklärt.

----------

## WiredEd

Eine sehr nette Diskussion hier. Freut mich zu lesen, dass es doch noch einige Java-Freunde gibt, die anscheinend nicht nur aus beruflichen Gründen in Java programmieren, sondern auch, weil sie die Vorteile dieser Sprache für den Entwickler zu schätzen wissen. Die Einzelheiten dazu will ich hier aber nicht noch einmal wiederholen.

Zum Thema Performance möchte ich hier nur noch eine einigermassen seriöse Quellenangabe nachreichen:

C#, Java, C++ und Delphi im Effizienztest

In c't 19/03 ab Seite 204 und c't 21/03 ab Seite 222 wurde der Versuch gewagt, anhand von kleinen Programmbeispielen in den verschiedenen Sprachen (damals noch/schon Java 1.4.2), einige Performancemessungen zu machen. Das ganze auf einem Athlon 1GHz, und einem P4 2GHz. Die Ergebnisse waren teilweise erstaunlich, und spiegeln auch die hier weiter oben im Thread gebrachten Beispiele wieder.

Sehr interessanter Artikel.

----------

## SinoTech

 *McPringle wrote:*   

> 
> 
> Zu 1: Java ist keine interpretierte Sprache mehr. Schon seit Jahren nicht mehr. Der Java Quellcode wird vom Entwickler in Bytecode compiliert. Dieser Zwischencode wird von der VM vor der Ausfuehrung in nativen Code gewandelt - und zwar, das ist das besondere, unter Beruecksichtigung der aktuellen Gegebenheiten, das bedeutet auch unter Beruecksichtigung der Funktionen der verfuegbaren Prozessoren. Habe ich als User einen P4 nutzt die VM automatisch beim Kompilieren alles, was dieser Prozessor kann.
> 
> 

 

Hmm. ... aber soviel ich weiß wird diese kompilierung nur für als "final" deklarierte Methoden gemacht, was in der Praxis, zumindest bei mir, die wenigsten sind.

 *Quote:*   

> 
> 
> Zu 2. Siehe auch 1. Bytecode wird nur dann von der VM interpretiert, wenn eine Kompilierung keinen Sinn machen wuerde. Um das festzustellen, laeuft innerhalb der VM ein Analysierungs- und Optimierungsprozess - waehrend der kompletten Laufzeit der Anwendung. Dieser Prozess ist nicht fest sondern "lernt" auch dazu.
> 
> 

 

Siehe 1.

 *Quote:*   

> 
> 
> Zu 3: Reine Logik. Wenn eine Softwarefirma eine CS-Anwendung vertreibt, soll diese auf moeglichst vielen Rechnern laufen. Nehmen wir als Beispiel eine Windows-Anwendung. Wenn ich als Anwender im Laden eine Software kaufe, erwarte ich, dass sie auch noch auf dem hier neben mir stehenden Windows-PC mit einem Pentium 2 Prozessor laeuft. Genauso wie auf meinem Hauptrechner mit Pentium 4. Der Hersteller kann also beim Kompilieren seines C/C++-Programmes nur den kleinsten gemeinsamen Nenner beruecksichtigen. Da Java hingegen on-the-fly optimiert und in nativen Code kompiliert, ist Java in vielen Bereichen schneller als eine C/C++-Anwendung. Es sei denn, auch die C/C++-Anwendung wird auf genau dieses System hin optimiert, dann waeren sie in etwa gleichwertig. Allerdings hat Java dann immer noch seinen innerhalb der VM laufenden analysierenden und lernfaehigen Optimizer.
> 
> 

 

Mag sein das ich hier falsch liege, aber selbst wenn der Bytecode vor der Ausführung in nativen Code umgewandelt wird, so läuft das Programm nicht direkt über das Betriebssystem sondern über die JVM welche dann die Befehle an das Betriebssystem weitergibt. Es mag sein das das sehr schnell von statten geht aber dennoch ist hier ein zwischen Schritt drinn der bei C/C++ Programmen entfällt. Bin mir daher nicht sicher ob der optimierte JAVA Code wirklich schneller ist als ein gut geschriebenes C/C++ Programm ohne Optimierung. Habe es aber ehrlich gesagt auch noch nie ausprobiert.

Mfg

Sino

----------

## ZX-81

 *SinoTech wrote:*   

>  *McPringle wrote:*   
> 
> Zu 1: Java ist keine interpretierte Sprache mehr. Schon seit Jahren nicht mehr. Der Java Quellcode wird vom Entwickler in Bytecode compiliert. Dieser Zwischencode wird von der VM vor der Ausfuehrung in nativen Code gewandelt - und zwar, das ist das besondere, unter Beruecksichtigung der aktuellen Gegebenheiten, das bedeutet auch unter Beruecksichtigung der Funktionen der verfuegbaren Prozessoren. Habe ich als User einen P4 nutzt die VM automatisch beim Kompilieren alles, was dieser Prozessor kann.
> 
>  
> ...

 

Nein, final hat damit absolut nichts zu tun. 

 *SinoTech wrote:*   

>  *McPringle wrote:*   
> 
> Zu 3: Reine Logik. Wenn eine Softwarefirma eine CS-Anwendung vertreibt, soll diese auf moeglichst vielen Rechnern laufen. Nehmen wir als Beispiel eine Windows-Anwendung. Wenn ich als Anwender im Laden eine Software kaufe, erwarte ich, dass sie auch noch auf dem hier neben mir stehenden Windows-PC mit einem Pentium 2 Prozessor laeuft. Genauso wie auf meinem Hauptrechner mit Pentium 4. Der Hersteller kann also beim Kompilieren seines C/C++-Programmes nur den kleinsten gemeinsamen Nenner beruecksichtigen. Da Java hingegen on-the-fly optimiert und in nativen Code kompiliert, ist Java in vielen Bereichen schneller als eine C/C++-Anwendung. Es sei denn, auch die C/C++-Anwendung wird auf genau dieses System hin optimiert, dann waeren sie in etwa gleichwertig. Allerdings hat Java dann immer noch seinen innerhalb der VM laufenden analysierenden und lernfaehigen Optimizer.
> 
>  
> ...

 

Nein, der JIT Compiler erzeugt Maschinencode der direkt auf dem Zielprozessor läuft. In der Praxis sehe ich jedoch keinen signifikanten Laufzeitvorteil für Java, es ist vielmehr so, dass die unterschiedlichen Compiler etwas unterschiedlichen Code für verschiedene Konstrukte erzeugen. So liegt in einem Benchmark der Java JIT Compiler vorn, in einem anderen dann wieder z.B. gcc ...

----------

## McPringle

 *SinoTech wrote:*   

> Hmm. ... aber soviel ich weiß wird diese kompilierung nur für als "final" deklarierte Methoden gemacht, was in der Praxis, zumindest bei mir, die wenigsten sind.

 

Da liegst Du falsch. Die Optimierungen greifen fuer die gesamte Applikation.

 *SinoTech wrote:*   

> Mag sein das ich hier falsch liege, aber selbst wenn der Bytecode vor der Ausführung in nativen Code umgewandelt wird, so läuft das Programm nicht direkt über das Betriebssystem sondern über die JVM welche dann die Befehle an das Betriebssystem weitergibt. Es mag sein das das sehr schnell von statten geht aber dennoch ist hier ein zwischen Schritt drinn der bei C/C++ Programmen entfällt. Bin mir daher nicht sicher ob der optimierte JAVA Code wirklich schneller ist als ein gut geschriebenes C/C++ Programm ohne Optimierung. Habe es aber ehrlich gesagt auch noch nie ausprobiert.

 

Wie optimierst Du ein C/C++-Programm, wenn Du es kompilierst? Bietest Du, wenn Du ein Programm vertreibst, dieses fuer jeden kaeuflich zu erwerbenden Prozessor optimiert an? Bei uns laeuft auch ein Server mit UltraSPARC IIe Prozessor. Wie sieht es da mit Optimierungen aus? Noch mehrere Beispiele aus unserem Rechnerpool: Intel XEON, Pentium 4, Pentium 3, Pentium 2, Celeron, Duron und ein Transmeta Efficeon. Wenn ich nun ein C/C++-Programm nehme und auf diesen Rechnern ausfuehren moechte, muss ich den kleinsten gemeinsamen Nenner nehmen und es darauf optimieren. Mehr geht nicht - es sei denn ich mache mir den Aufwand, es fuer jeden Rechner einzeln zu optimieren. Dieser Aufwand steht jedoch in keinem Verhaeltnis zum Nutzen, denn das Deployment wird dadurch ebenfalls aufwendiger.

Mittels eines Java-Programmes wird durch die VM immer optimiert. Ich kann das gleiche Binary auf allen unterstuetzten Plattformen ausfuehren und erhalte immer optimale Performance (von Fehlern des Programmierers, die behindernd wirken koennten, einmal abgesehen). Das wird das Deployment einfacher. Und natuerlich auch die Testphasen, denn die VMs muessen einem Standard genuegen. Die VM wird auf einem Zielsystem getestet und wenn diese validiert, brauchen die Java-Programme nicht gesondert fuer diese eine Plattform gestestet zu werden. Java hat sowohl fuer den Entwickler, als auch fuer den Adminitrator und den Anwender grosse Vorteile gegenueber C/C++.

Noch dazu kommt, dass es sehr viele Szenarien gibt, die von verschiedenen Organisationen und Publikationen dargestellt werden, in denen Java nicht nur in der Theorie, sondern auch in der Praxis schneller ist als C/C++ (siehe beispielsweise das Posting von WiredEd, der auf Performancemessungen vom Heise-Verlag hingewiesen hat). Selbst fuer den Fall dass eine bestimmte Aufgabe mit C/C++ effizienter bewaeltigt werden kann, so kann man von Java aus auch auf Bibliotheken, die beispielsweise in C/C++ geschrieben sind, zurueckgreifen (JNI - Java Native Interface). Allerdings musste ich das waehrend meiner gesamten Laufbahn nur ein einziges mal tun - als es gewuenscht wurde, waehrend der Laufzeit ein Symbol im Systray von Windows einzublenden, und das hatte nichts mit Geschwindigkeit zu tun...

McPringle

----------

## Ragin

 *ZX-81 wrote:*   

> Wenn Java Server Pages auch nur annähernd so langsam und resourcenfressend wie PHP wären, wurde ich keine Web-Anwendungen damit entwickeln.

 

Wenn du dich da mal nicht vertust. PHP ist in vielen Fällen mind. genausoschnell wie JSP und zu 99% extrem Ressourcenschonender. Schau dir mal an, was ein Java-Prozess auf Dauer allein für RAM schluckt. Bei PHP läuft das selbst bei Anwendungen, wo 1000 Besucher/Sekunde zugreifen (hab soetwas programmiert) nur im Rahmen von 8-10MB. Java dagegen benötigt dagegen ein vielfaches. CPU-Auslastung ist bei beiden gleich, bei komplexeren Anwendungen ist Java sogar etwas CPU-lastiger. Leider gibt es aber auch zu viele PHP-Programmierer, die meinen man müsse in der Hauptdatei erstmal 100 Einträge inkludieren und dann schauen, was man eigentlich braucht. Dann fressen die Plattenzugriffe die ganze Performance, aber insgesamt würde ich beide als gleichschnell einstufen. Java ist nur sicherer und bietet einige Möglichkeiten, die PHP nicht bietet, PHP dagegen lässt sich schneller und einfacher programmieren (was aber auch nicht immer das beste ist).

----------

## petter_r

Man kann PHP und J2EE Anwendungen nur bedingt vergeleichen, da ein J2EE Server einfach ganz andere Möglichkeiten wie z.B. Connection Pooling Dynamic Cache usw. bietet. Das ist aber schon ziemlich OT da es nichts mit der Performance von Java zu tun hat. Trotzdem bleibt die Tatsache, dass die Performance und skalierbarkeit von J2EE der von PHP basierenden Server weitüberlegen. Ich denke Projekte wie die Wikipedia sind ein gutes Beispiel, dass PHP eine sehr gute Lösung für kleinere und mittlere Lasten ist, aber wenn das Projekt weiterwächst, dann kommt man irgendwann zu dem Punkt wo ich die schnellste Hardware die Defizite von PHP basierten Server nicht mehr ausgleichen können.

Das der Hauptspeicherbedarf von wirklichen OO Sprachen immer höher ist, als in anderen vergleichbaren Systemen muß auch nicht diskutiert werden.

Grüße

Ralf

----------

## Inte

 *c07 wrote:*   

> Java ist [...] für lokale Anwendungen ist es sowieso höchstens als Notlösung geeignet.

 

Ist das in Deinen Augen auch eine Notlösung? (Soll nur ein kleiner Denkanstoss sein  :Razz: )

https://forums.gentoo.org/viewtopic-t-183095.html

```
*  x11-misc/lookingglass-bin

      Latest version available: 0.5

      Latest version installed: [ Not Installed ]

      Size of downloaded files: 7,775 kB

      Homepage:    https://lg3d.dev.java.net/

      Description: Looking Glass - 3D window manager written in Java

      License:     GPL-2
```

----------

## SinoTech

 *McPringle wrote:*   

> 
> 
>  *SinoTech wrote:*   
> 
> Hmm. ... aber soviel ich weiß wird diese kompilierung nur für als "final" deklarierte Methoden gemacht, was in der Praxis, zumindest bei mir, die wenigsten sind.
> ...

 

OK, habe mich da etwas geirrt. Das mit den "final" Funktionen ist etwas anderes (Können optimiert werden da diese in keinen Unterklassen überschirben werden können und von daher die Typprüfung entfällt. Hat aber nichts mit dem kompilieren in nativen Code zu tun).

Das einzige was mich ansonsten etwas an Java gestört hat, zumindest an einer früheren Version von Blackdown, war das er mir den Speicher nicht wieder freigegeben hat. Hatte mal ein Projekt mit Maple das ich aber nur 3 mal berechnen lassen konnte weil danach der komplette Speicher zugemüllt war und ich Maple neu starten musste. Hat sich aber bei der neuen version erledigt.

Mfg

Sino

----------

## Ragin

@Inte:

schieß nicht gleich mit so schweren Geschützen  :Smile: . Wollen ja keinen hier verletzen  :Smile: .

@SinoTech:

Blackdown hatte bei mir auch ständig irgendwelche Probleme. Daher bin ich auf das sun-java Paket umgestiegen. Dieses läuft etwas stabiler und Killeranwendungen wie Eclipse brechen nicht ständig ab (oder starten gar nicht erst). Zumindest war dies bei mir auf 3 Rechnern zu verzeichnen.

----------

## SinoTech

 *Ragin wrote:*   

> 
> 
> @SinoTech:
> 
> Blackdown hatte bei mir auch ständig irgendwelche Probleme. Daher bin ich auf das sun-java Paket umgestiegen. Dieses läuft etwas stabiler und Killeranwendungen wie Eclipse brechen nicht ständig ab (oder starten gar nicht erst). Zumindest war dies bei mir auf 3 Rechnern zu verzeichnen.
> ...

 

Naja, abbrechen tut bei mir zum Glück nichts. Nur der start dauert dafür ewig (Eclipse und Together Designer brauchen ca. 30 - 40 sec. zum Start). Werd glaub auch mal das SUN Packet ausprobieren.

Mfg

Sino

----------

## Carlo

 *McPringle wrote:*   

>  *Carlo wrote:*   Ich habe absolut nichts gegen Java, aber Swing ist (solange ich es irgendwie verantworten kann) Ausschlußgrund für eine Anwendung. 
> 
> Weshalb? Bitte begruende das doch.

 

Sicher ist es Geschmackssache. Ich kriege allein bei den Treeview-Knoten das Würgen. Von Standard-GUI+Farbwahl gar nicht zu reden. Daß ich ein gebranntes Kind aus JDK 1.2 Zeiten bin, ist der Sache auch nicht förderlich.

 *McPringle wrote:*   

> Denn Swing unterstuetzt das Wechseln des Look-n-Feels (oft "themable" genannt, aber mit diesem nicht vergleichbar, da sehr viel leistungsfaehiger). Mit den verschiedenen Look-n-Feels, die man natuerlich auch selbst erstellen kann, kann man eine auf Swing basierende Anwendung nicht nur komplett verschieden aussehen sondern sich auch komplett verschieden anfuehlen (bedienen) lassen. Man kann Swing sogar das aktuelle GNOME- oder KDE-Theme nutzen lassen.

 

Ich vermute Du redest hier von Java 1.5, was ich mir noch nicht angetan habe. Jedenfalls ist mir - abgesehen von Eclipse mit gtk-qt-engine - noch keine Java-Applikation untergekommen, die sich halbwegs nahtlos in meinen Desktop einfügt.

Rein prinzipiell ist das Problem natürlich nicht nur auf die GUI oder Java bechränkt. Z.B. Shortcuts oder allgemein das, was sich in divergierenden HIGs niederschlägt, sollte in Standards gegossen und in einer Pluginstruktur implementiert werden, auf die sämtliche Anwendungen zugreifen. Letztendlich geht es die Anwendungen oder dahinter stehende Toolkits (und ihre Entwickler) nicht das geringste an, was der Anwender systemweit vorgeben möchte.

----------

## TheSmallOne

-–- gelöscht -–-Last edited by TheSmallOne on Tue Dec 25, 2012 10:45 pm; edited 1 time in total

----------

## McPringle

 *Carlo wrote:*   

> Ich vermute Du redest hier von Java 1.5, was ich mir noch nicht angetan habe. Jedenfalls ist mir - abgesehen von Eclipse mit gtk-qt-engine - noch keine Java-Applikation untergekommen, die sich halbwegs nahtlos in meinen Desktop einfügt.

 

Nein, ich rede von Java Versionen ab 1.2, denn seit dieser Version gehoert Swing zum Standard-Lieferumfang. Und Swing ist pluggable. Man kann Anwendungen aussehen und anfuehlen lassen, wie man moechte. Mit Eclipse ist das Umschalten des LF (Look-n-Fells) nicht moeglich, da es auf SWT setzt und kein Swing benutzt. Wenn Du moechtest, dass sich eine Java-Applikation anders anfuehlt oder sie anders aussieht, dann steht es Dir frei, sie entsprechend zu konfigurieren. Das kannst Du sogar machen, wenn der Entwickler der Applikationen keine Moeglichkeit zum Wechsel des LFs vorgesehen hat.

Java diese Moeglichkeit ganzlich abzusprechen, nur weil man sie nicht kennt oder noch nie genutzt hat, ist weit mehr als unfair.

 *Carlo wrote:*   

> Rein prinzipiell ist das Problem natürlich nicht nur auf die GUI oder Java bechränkt. Z.B. Shortcuts oder allgemein das, was sich in divergierenden HIGs niederschlägt, sollte in Standards gegossen und in einer Pluginstruktur implementiert werden, auf die sämtliche Anwendungen zugreifen. Letztendlich geht es die Anwendungen oder dahinter stehende Toolkits (und ihre Entwickler) nicht das geringste an, was der Anwender systemweit vorgeben möchte.

 

Zur Integration in GUis - heute habe ich die Applikationen eines Bekannten ueber seine Website gestartet und Java hat mich gefragt (da es sich um den ersten Start dieser Applikation handelte), ob es sie in meinen Desktop (aktuell GNOME) integrieren moechte. Ich habe dieses bejaht und nun einen Eintrag im Startmenue. So einfach kann man kein C/C++-Programm installieren (ausser vielleicht mit Hilfe spezieller Distributionsloesungen wie beispielsweise den NAL).

Zur den von Dir angesprochenen HIGs - sich an Standards fuer Benutzeroberflaechen zu halten ist ja nun eindeutig Aufgabe des Entwicklers und hat absolut nichts mit der verwendeten Programmiersprache zu tun. Ich halte mich bei der Entwicklung kit Java genauso an Standards wie es auch schon zu Beginn meiner Laufbahn mit Comal und Pascal tat.

Die von Dir angesprochene Flexibilitaet bei der Gestaltung der Vorgaben durch Anwender hat gerade Java die Nase vor C/C++ ... :Very Happy: 

McPringle

----------

## Carlo

 *McPringle wrote:*   

> Nein, ich rede von Java Versionen ab 1.2

 

Also ich habe schon recht lange nicht mehr das zweifelhafte Vergnügen mit Swing gehabt. Allerdings auch nicht so lange. Jedenfalls gab's da keine Option mein KDE Theme zu benutzen. Und damit meine ich nicht gerade eben so ähnlich. Ich konnte den klassischen Windows-Look von Swing-Applikationen auch nie leiden und zweifle, daß sich da irgendwas verbessert haben sollte.

 *McPringle wrote:*   

> Die von Dir angesprochene Flexibilitaet bei der Gestaltung der Vorgaben durch Anwender hat gerade Java die Nase vor C/C++ ...

 

Java ist - für sich genommen - etwas besser, aber Du hast was HIGs etc. angeht, hast Du mich mißverstanden. Es geht um die Abstraktion von Toolkit und Interaktion. Welche Darstellung (Vektor/Pixel, was für ein Theme auch immer), welche Shortcuts der Anwender (z.B. für Kopieren strg+c oder alt+k) verwenden möchte oder ob der Ok Button links oder rechts vom Cancel Button sitzt, sollte systemweit über Module definiert werden die sich der Anwender aussucht und in die sich die Toolkits (sei es Java, Qt, WxWidgets oder was auch immer) über eine standardisierte Schnittstelle gefälligst einzuklinken haben.

----------

## return13

 *Das Buch das ich gerade lese... wrote:*   

> 
> 
> C++ runs extremely fast and is in fact 10 to 20 times FASTER than Java. Java runs very slow because it is a byte code interpreted language running on top of "virtual machine". Java runs faster with JIT (Just In Time) compiler, but it is still slower than C++. And optimized C++ program is about 3 to 4 times faster than Java (with JIT compiler). Then, why do people use Java? Because it is pure object oriented and is easier to program in Java, as Java automates memory management, and programmers do not directly deal with memory allocations.

 

Ist diese Aussage an sich so wie es steht also falsch?

Also ihr sagt alle das Java mindestens genau so schnell ist wie C/C++ Code,

ich will euch ja glauben, und es wäre für mich auch sehr viel einfach java zu lernen anstatt mit C/C++ zu versuchen kompatibilität zu schaffen,

nur ist nunmal das was ich während meiner täglichen arbeit am PC gelernt hab das Java anwendungen genau das gegenteil von dem sind was

ihr hier zu erklären versucht...

Ich wäre glücklich wenns tatsächlich so wär nur, zumindest auf meinem Rechner mit meinen Java Programmen, ists nicht so...

Meine Erfahrung sagt das Java länger braucht...

----------

## ZX-81

 *return13 wrote:*   

>  *Das Buch das ich gerade lese... wrote:*   
> 
> C++ runs extremely fast and is in fact 10 to 20 times FASTER than Java. Java runs very slow because it is a byte code interpreted language running on top of "virtual machine". Java runs faster with JIT (Just In Time) compiler, but it is still slower than C++. And optimized C++ program is about 3 to 4 times faster than Java (with JIT compiler). Then, why do people use Java? Because it is pure object oriented and is easier to program in Java, as Java automates memory management, and programmers do not directly deal with memory allocations. 
> 
> Ist diese Aussage an sich so wie es steht also falsch?
> ...

 

Definitiv, für den interpretierten Bytecode bin ich sogar auf Faktor 40 gekommen, aber mit modernen JIT-Compilern ist kein signifikanter Unterschied mehr festzustellen. Wann wurde denn das Buch herausgegeben?

 *return13 wrote:*   

> 
> 
> Also ihr sagt alle das Java mindestens genau so schnell ist wie C/C++ Code,
> 
> ich will euch ja glauben, und es wäre für mich auch sehr viel einfach java zu lernen anstatt mit C/C++ zu versuchen kompatibilität zu schaffen,
> ...

 

Bisher ging es immer um die Geschwindigkeit der VM und die ist definitiv nicht der bremsende Faktor. Dass es dennoch viele ineffiziente Java Anwendungen gibt liegt IMHO hauptsächlich daran, dass in Java nicht dasselbe "Survival of the fittest" wie in C++ stattfindet. Der Kenntnisstand den man braucht um halbwegs lauffähige Programme zu entwickeln ist in Java um Größenordnungen geringer als in C++.

----------

## TheRelevator

Was ist ein JIT Compiler? Und wo kriege ich den her?

----------

## McPringle

 *TheRelevator wrote:*   

> Was ist ein JIT Compiler? Und wo kriege ich den her?

 

Der steckt in der JRE drin. Lade einfach eine aktuelle JRE, beispielsweise Java 5.

cu

McPringle

----------

## McPringle

 *Carlo wrote:*   

> Also ich habe schon recht lange nicht mehr das zweifelhafte Vergnügen mit Swing gehabt. Allerdings auch nicht so lange. Jedenfalls gab's da keine Option mein KDE Theme zu benutzen. Und damit meine ich nicht gerade eben so ähnlich. Ich konnte den klassischen Windows-Look von Swing-Applikationen auch nie leiden und zweifle, daß sich da irgendwas verbessert haben sollte.

 

Du scheinst Dich nicht ernsthaft mit Swing auseinander gesetzt zu haben. In den Tutorials von SUN ist jedenfalls die Rede davon, wie man das LF wechselt. In allen mir bekannten Buechern zu Java ebenfalls. Nehme einfach ein LF, dass KDE- oder GNOME-Themes nutzt. Schon sieht Deine Java-Anwendung so aus wie Deine KDE- bzw. GNOME-Anwendungen. It's really easy, boy...  :Smile: 

 *Carlo wrote:*   

> Java ist - für sich genommen - etwas besser, aber Du hast was HIGs etc. angeht, hast Du mich mißverstanden. Es geht um die Abstraktion von Toolkit und Interaktion. Welche Darstellung (Vektor/Pixel, was für ein Theme auch immer), welche Shortcuts der Anwender (z.B. für Kopieren strg+c oder alt+k) verwenden möchte oder ob der Ok Button links oder rechts vom Cancel Button sitzt, sollte systemweit über Module definiert werden die sich der Anwender aussucht und in die sich die Toolkits (sei es Java, Qt, WxWidgets oder was auch immer) über eine standardisierte Schnittstelle gefälligst einzuklinken haben.

 

Gibts auch schon lange. Da verweise ich gerne auf die JGoodies Forms, die Methoden dafuer bereit stellen und sich automatisch an die HIGs der jeweiligen Systemplattform halten (Dialoge haben so beispielsweise auf Macs eine andere Reihenfolge der Buttons wie auf Windows oder Linux). On man diese Frameworks nutzt oder nicht, bleibt den Entwicklern ueberlassen. Mehr als anbieten kann man es nicht...

cu

McPringle

----------

## McPringle

 *return13 wrote:*   

> Ist diese Aussage an sich so wie es steht also falsch?

 

Nein, nur veraltet. Meine Erfahrungen mit Java-Anwendungen sehen anders auch - auch wenn es natuerlich schlechte Beispiele gibt, wenn der Entwickler sich nicht um die Eigenheiten von Java und objektorientierter Entwicklung schert - aber das hat man auf jedem System mit jeder Sprache (bei Java wohl mehr als bei C/C++, da die Einstiegshuerden fuer unerfahrene Entwickler geringer sind)...

cu

McPringle

----------

## ZX-81

Dank gcj kann man übrigens auch aus Java Binaries erzeugen.  

gcj erhält man, wenn man das use flag "gcj" (EDIT: Das stand vorher java, Danke SinoTech) entweder global "/etc/make.conf" oder in "/etc/portage/package.use" bei gcc angibt und gcc neu emerged.

ZXLast edited by ZX-81 on Fri Mar 18, 2005 4:22 pm; edited 1 time in total

----------

## SinoTech

 *ZX-81 wrote:*   

> Dank gcj kann man übrigens auch aus Java Binaries erzeugen.  
> 
> gcj erhält man, wenn man das use flag "java" entweder global "/etc/make.conf" oder in "/etc/portage/package.use" bei gcc angibt und gcc neu emerged.
> 
> ZX

 

USE_Flag heißt "gcj"  :Smile: 

Mfg

Sino

----------

## Carlo

 *McPringle wrote:*   

> Du scheinst Dich nicht ernsthaft mit Swing auseinander gesetzt zu haben.

 

Das bestreite ich ja gar nicht. Die Anwendungen, die ich mir angeschaut habe, waren abschreckend (bzgl. Speicherverbrauch, graphisch nicht ansprechend und träge GUI) und der Bedarf sich weiter mit Java auf dem Desktop auseinanderzusetzen war nie da. Wobei in der Zwischzeit in der Tat interessantere Java-basierende Applikationen auf den Markt gekommen sind.

 *McPringle wrote:*   

> Gibts auch schon lange. Da verweise ich gerne auf die JGoodies Forms

 

Wie gesagt ist das schön und gut für Java, aber ich würde es vorziehen, wenn es eine selbstständige Systemkomponente wäre, auf der alle Toolkits aufsetzen. Die Crux ist, daß es unter *nix derartige Standards nicht gibt, während man bei anderen Systemen die Vorstellungen des Herstellers aufgezwungen bekommt. 

 *McPringle wrote:*   

> On man diese Frameworks nutzt oder nicht, bleibt den Entwicklern ueberlassen. Mehr als anbieten kann man es nicht...

 

Jein.  :Smile: 

----------

## schachti

 *ZX-81 wrote:*   

> 
> 
> Dank gcj kann man übrigens auch aus Java Binaries erzeugen.  
> 
> 

 

Was ist denn der Vorteil dieser Binaries? Geringere Ladezeit?

----------

## return13

 *ZX-81 wrote:*   

> 
> 
> Wann wurde denn das Buch herausgegeben?
> 
> 

 

Juli 2001 erschien das buch...

----------

## Ragin

 *return13 wrote:*   

> Juli 2001 erschien das buch...

 

Seither gabs aber schon einige Änderungen bei Java  :Smile: 

Das dürfte sich sogar noch auf Java 1.3 oder sogar 1.2 beziehen.

Daher sind die darin enthaltenen Texte in Bezug auf Performance (sogar teilweise auf Befehle/Syntax) weitestgehend überholt.

----------

## SinoTech

Hab anscheinst das gleiche Buch, zumindest ist das gleiche Statement enthalten. Meines ist von 2002 und bzeiht sich auf Version 1.4.

Wie auch immer ich muss "retrn13" schon Recht geben. Gefühlsmäsig können die Java Programme, zumindest bei mir, bei weitem nicht mit C/C++ Programmen mithalten.

Allein die Startzeit ist schon eine Zumutung (ca. 40 Sekunden für Eclipse bzw. Together Designer) obwohl ich das noch verkraften könnte wenn da wirklich etwas in nativen Code umgewandelt werden würde und die Performance beim eigentlich arbeiten dann besser wäre. Aber auch das Arbeiten geht nicht so richtig flüssig wie ich das von anderen Programmen her kenne. Stehe also euren Statements von wegen "optimierungen" etc. etwas skeptisch gegenüber (Was natürlich nicht heißen das ihr lügt  :Very Happy:  ).

Mfg

Sino

----------

## return13

dann muss man ja quasi jedes jahr neue Java bücher kaufen, um überhaupt einigermaßen akzeptablen Code zu produzieren...

----------

## Voltago

Bücher kauft man doch eh nur als Einsteiger. Danach ist das Web aktueller und billiger:

http://java.sun.com/learning/tutorial/index.html

http://onjava.com

----------

## Ragin

@SinoTech:

Gerade bei Eclipse muss ich dir Recht geben. Die Performance ist dort teilweise derart schlecht, dass ich schon (gerade unter Linux) gar nix mehr damit mache. Auf Arbeit muss ich Eclipse unter Windows nutzen und muss sagen, dass es bis zur Version 3.0M9 recht gut lief, dann allerdings einen extremen Performanceabbruch hatte. Inzwischen scheint es wieder etwas schneller zu laufen.

Andererseits sind Programme wie NetBeans recht fix. Allerdings muss man bei Eclipse hier noch ein auge zudrücken, da es ein arg großes Programm ist (was ich ehrlich gesagt auch nicht wirklich verstehe).

@return13:

Nein, du musst nicht jedes Jahr ein neues Buch kaufen, aber ich habe gemerkt, dass gerade in Java 5 viele Änderungen gekommen sind, die so manche Funktion grundlegend geändert/überflüssig gemacht haben oder sie einfach entfernt wurden. Der Sprung von 1.3 auf 1.4 war da bei weitem nicht so gravierend.

----------

## ZX-81

 *schachti wrote:*   

>  *ZX-81 wrote:*   
> 
> Dank gcj kann man übrigens auch aus Java Binaries erzeugen.  
> 
>  
> ...

 

Unter anderem, gerade zum Ausführen von kleineren Tools muss dann nicht erst die dicke VM angeworfen werden. Auf dem Zielsystem muss dann gar keine VM installiert sein. Habe damit allerdings ausser ein paar kleinen Tests noch nichts gemacht. In ct stand aber dass es ein paar Libraries gibt die man damit nicht verwenden kann (Swing z.B., SWT (GUI Library von Eclipse) soll aber funktionieren).

----------

## ZX-81

 *Ragin wrote:*   

> @SinoTech:
> 
> Gerade bei Eclipse muss ich dir Recht geben. Die Performance ist dort teilweise derart schlecht, dass ich schon (gerade unter Linux) gar nix mehr damit mache. Auf Arbeit muss ich Eclipse unter Windows nutzen und muss sagen, dass es bis zur Version 3.0M9 recht gut lief, dann allerdings einen extremen Performanceabbruch hatte. Inzwischen scheint es wieder etwas schneller zu laufen.
> 
> Andererseits sind Programme wie NetBeans recht fix. Allerdings muss man bei Eclipse hier noch ein auge zudrücken, da es ein arg großes Programm ist (was ich ehrlich gesagt auch nicht wirklich verstehe).
> ...

 

Interessant wie unterschiedlich doch die Erfahrungen sind. Ich habe genau die Gegenteiligen gemacht, sowohl bezüglich Windows und Linux, wie auch bezüglich Netbeans und Eclipse. Bei Netbeans muss ich allerdings sagen, dass das schon eine Weile her ist. Bei der Arbeit mit Java ist eine ausreichende Größe des Arbeitsspeichers sehr wichtig. Unter 512 MB macht es keinen Spaß. Und die Ladezeiten sind wirklich recht lange, aber das Teil (Eclipse) läuft so stabil, dass ich es nur einmal am Tag starten muss.

----------

## Ragin

Bei NetBeans meinte ich auch die neuste Version (5?).

Und bei Eclipse war es auch nur eine Version der 3.0.1er Reihe (gabs ja glaub auch mehrere Releases).

Danach war es auf einmal wieder wunderbar schnell.

Am RAM kann es bei einem PIV 3Ghz mit 1GB RAM nicht liegen, genausowenig wie an der CPU  :Smile: .

Es muss also etwas anderes gewesen sein  :Smile: 

----------

## SinoTech

 *Ragin wrote:*   

> @SinoTech:
> 
> Gerade bei Eclipse muss ich dir Recht geben. Die Performance ist dort teilweise derart schlecht, dass ich schon (gerade unter Linux) gar nix mehr damit mache. Auf Arbeit muss ich Eclipse unter Windows nutzen und muss sagen, dass es bis zur Version 3.0M9 recht gut lief, dann allerdings einen extremen Performanceabbruch hatte. Inzwischen scheint es wieder etwas schneller zu laufen.
> 
> Andererseits sind Programme wie NetBeans recht fix. Allerdings muss man bei Eclipse hier noch ein auge zudrücken, da es ein arg großes Programm ist (was ich ehrlich gesagt auch nicht wirklich verstehe).
> ...

 

Naja ... Auge zu drücken fällt mir schwer. Habe sehr lange mit Visual C++ 6.0 gearbeitet was auch relativ groß war. Und das startete beim Erststart innerhalb von ~ 6 Sekunden und bei jedem weiteren Start innerhalb von ~2 Sekunden. Eclipse ist davon sehr, sehr weit entfernt. Und während dem arbeiten ist es auch sehr mühsam von einer Datei in die nächste zu wechseln.

Naja, eclipse und Together sind zur Zeit aber auch die einzigsten Java Programme die ich nutze. Möglich das gerade diese beiden schlecht Programmiert sind und ein  schlechte Licht bei mir auf auf Java werfen (Hatte zeitweise noch Maple benutzt, aber habe da keinen Vergleich zu einer C/C++ Version da ich nur die Java-Version besitze).

Mfg

SinoTech

----------

## ZX-81

 *SinoTech wrote:*   

> Naja ... Auge zu drücken fällt mir schwer. Habe sehr lange mit Visual C++ 6.0 gearbeitet was auch relativ groß war. Und das startete beim Erststart innerhalb von ~ 6 Sekunden und bei jedem weiteren Start innerhalb von ~2 Sekunden. Eclipse ist davon sehr, sehr weit entfernt. Und während dem arbeiten ist es auch sehr mühsam von einer Datei in die nächste zu wechseln.
> 
> Naja, eclipse und Together sind zur Zeit aber auch die einzigsten Java Programme die ich nutze. Möglich das gerade diese beiden schlecht Programmiert sind und ein  schlechte Licht bei mir auf auf Java werfen (Hatte zeitweise noch Maple benutzt, aber habe da keinen Vergleich zu einer C/C++ Version da ich nur die Java-Version besitze).

 

Visual C++ kenne ich bis zur Version 6.0 auch recht gut. Dass das Starten grosser Java Anwendungen länger dauert ist wegen JIT nicht verwunderlich. Mich stören jedoch die 20/10 Sekukunden nicht, die Eclipse auf meinem Notebook (P-M 1,5 GHz)  unter gentoo zum Starten braucht. Es gibt auch einige Stellen an denen sich Visual C++ bzw. das Developer-Studio wesentlich agiler anfühlt. Allerdings ist der Funktionsumfang von Eclipse auch wesentlich höher und es hat bei mir noch kein Fehlverhalten gezeigt (mal von dem schrecklichen Lomboz-plugin abgesehen, Visual C++ ist öfter mal abgestürzt und hat andere Macken gehabt). Der entscheidende Punkt der gegen C++ spricht sind aber die Projekt Rebuild Zeiten. Die liegt bei einem Projekt bei fast einer Stunde. Der rebuild des gleichen Projekts unter Java benötigt nur eine Minute. Für Visual C++ kommt noch erschwerend hinzu, dass es häufig beim Auflösen der Abhängigkeiten versagt und dann unnötigerweise ein Rebuild notwendig wird.

ZX

----------

## garaone

hm... warum eigentlich immer diese diskussion, welche programmiersprache allgemein die bessere ist.

c/c++ und java, wie auch php haben jeweils ihre staerken auf ihrem gebiet... wo die andern kaum mithalten koennen.

bei gui sachen duerfte java auf lange sicht die bessere wahl sein. wegen seine plattformunabhaengigkeit. das schliesst jit optimierungen mit ein.

allerdings sind solche sachen wie binaries einbinden (jnt hiess das glaube?), meiner meinung keine gruende die fuer java zu sprechen. da dies das grundkonzept unterlaeuft. wenn man soweit kommt und java mit binaries mischt, kann man sich gleich ueberlegen auf c/c++ oder aehnliche sprachen umzusteigen.

allerdings wo es zeitkritisch wird und man die systemauswahl auf bestimmte prozessorgenerationen und typen einschraenken kann, oder sogar das system vorgegeben bekommt auf dem man zu programmieren hat, ist java in einer andern liga als mit c/c++.  in solchen faellen brauch man ein sprache die einem alle freiheiten gibt.

greets gara

----------

## MatzeOne

 *Ragin wrote:*   

> Bei NetBeans meinte ich auch die neuste Version (5?).
> 
> Und bei Eclipse war es auch nur eine Version der 3.0.1er Reihe (gabs ja glaub auch mehrere Releases).
> 
> Danach war es auf einmal wieder wunderbar schnell.
> ...

 

Meine Erfahrungen sind auch andere.

Netbeans 4.1 Early Access 2 lief auch auf meinem schwächeren Laptop (P3 1GHz, 512MB RAM) recht gut. Nie abgestürzt und die Ladezeiten sind auch aktzeptabel. Hier läuft noch das Blackdown-JDK, während auf meinem AMD64 das JDK von der Firma Sun zum Einsatz kommt.

Auch mit Eclipse 3.01, zu welchem ich als primäre Entwicklungsumgebung gerade wechsel, konnte ich bis jetzt nichts negatives, was Stabilität und Geschwindigkeit betrifft, feststellen.

Zur Programmiersprache Java selber:

Die Ausführungsgeschwindigkeit der Software ist meines Erachtens nicht unbedingt das Wichtigste. Die Entwicklung mit Java finde ich persönlich sehr angenehm. Ich denke bei den virtuellen Maschinen wird sich auch noch einiges an Performance rausholen lassen. Ich meine auch mal gelesen zu haben, dass CPUs in der Entwicklung sind, die (Java) Bytecode verstehen können.

----------

## SinoTech

 *ZX-81 wrote:*   

> 
> 
> Visual C++ kenne ich bis zur Version 6.0 auch recht gut. Dass das Starten grosser Java Anwendungen länger dauert ist wegen JIT nicht verwunderlich. Mich stören jedoch die 20/10 Sekukunden nicht, die Eclipse auf meinem Notebook (P-M 1,5 GHz)  unter gentoo zum Starten braucht. Es gibt auch einige Stellen an denen sich Visual C++ bzw. das Developer-Studio wesentlich agiler anfühlt. Allerdings ist der Funktionsumfang von Eclipse auch wesentlich höher und es hat bei mir noch kein Fehlverhalten gezeigt (mal von dem schrecklichen Lomboz-plugin abgesehen, Visual C++ ist öfter mal abgestürzt und hat andere Macken gehabt). Der entscheidende Punkt der gegen C++ spricht sind aber die Projekt Rebuild Zeiten. Die liegt bei einem Projekt bei fast einer Stunde. Der rebuild des gleichen Projekts unter Java benötigt nur eine Minute. Für Visual C++ kommt noch erschwerend hinzu, dass es häufig beim Auflösen der Abhängigkeiten versagt und dann unnötigerweise ein Rebuild notwendig wird.
> 
> ZX

 

Habe ja auch kein Problem damit wenn mal ein Programm etwas länger zum starten braucht, nur sollte dann wärend des arbeitens der Rest schon flüssig von der Hand gehen. Und ich habe in Eclipse die Erfahrung gemacht das es beim umschalten zwischen zwei Datein schon etwas hängt. Was Visual C++ angeht, so .. ja, es ist mir auch schon ein paar mal abgestürtzt (Eclipse hingegen noch nie) was mir aber nichts ausgemacht hat da es alle Einstellungen gespeichert hat und der Neustart nur etwa 2 Sekunden gedauert hat. Auch der Funktionsumfang lässt dort nichts zu wünschen Übrig (Bin mir nicht sicher ob Eclipse da mithalten kann. bzw. wenn dann muss man wahrscheinlich etliche Plugins installieren. Aber OK, ich muss zugeben das ich es bisher nur für ein paar kleinere Java-Projekte genutzt habe).

Mfg

Sino

----------

## Ragin

Genau das Problem hatte ich auch mit Eclipse. Zwischen Dateien wechseln war ein einziger Graus. Geschweigedenn eine Datei öffnen. Da konnte ich teilweise nen Kaffee nebenher trinken.

Ich habe aber bei einem Kollegen (der einen ~700MHz Rechner hat) Eclipse 3.0.1  oder 3.1 sehr flink laufen sehen. Als ich damals mit der Version getestet habe hatte ich es noch bei einem andern Kollegen auf dem PC probiert, was aber ebenfalls wie bei mir gescheitert ist. Irgendwie scheint es da 2 Versionen einer Version (Matrix lässt grüßen  :Smile: ) zu geben. Vielleicht teste ich am Montag mal die aktuell verfügbare Version aus. Mal sehen, ob sich das Problem inzwischen erledigt hat.

----------

## SinoTech

 *Ragin wrote:*   

> Genau das Problem hatte ich auch mit Eclipse. Zwischen Dateien wechseln war ein einziger Graus. Geschweigedenn eine Datei öffnen. Da konnte ich teilweise nen Kaffee nebenher trinken.
> 
> Ich habe aber bei einem Kollegen (der einen ~700MHz Rechner hat) Eclipse 3.0.1  oder 3.1 sehr flink laufen sehen. Als ich damals mit der Version getestet habe hatte ich es noch bei einem andern Kollegen auf dem PC probiert, was aber ebenfalls wie bei mir gescheitert ist. Irgendwie scheint es da 2 Versionen einer Version (Matrix lässt grüßen ) zu geben. Vielleicht teste ich am Montag mal die aktuell verfügbare Version aus. Mal sehen, ob sich das Problem inzwischen erledigt hat.

 

Guter Tip. Hab mir mal gerade die aktuelle Version von Eclipse besorgt (3.0.1) .. und siehe da, es flutscht richtig. Naja ok flutschen nicht direkt aber geht auf jeden Fall sehr viel besser.

Start dauert nur noch ca. 20 Sekunden und umschalten zwischen einzelnen Dateien geht, falls diese schon in einem Tab geöffnet sind, ruck zuck.

Eclipse 3.0.1

SUN-JDK-1.4.2.07

Mfg

Sino

----------

## ZX-81

In der Arbeit habe ich auch ein teilweise sehr träges Eclipse, liegt dort aber teilweise am Speichermangel und am zwangsinstallierten Virenscanner.

@sinotech: Eclipse bietet unter Source und Refactor einiges mehr als Visual C++. Recht praktisch finde ich es dass man einen unglücklich gewählten Methoden- oder Klassennamen damit ganz einfach ändern kann (In Visual C++ ist das so aufwendig (zumindest das Ändern des Klassennamens), dass oft die unpassenden Namen erhalten bleiben). Der Class-Browser funktioniert unter Eclipse auch hervorragend (Hat in grösseren VC Projekten nie funktioniert) und der Debugger ist genial (z.B. beim Debuggen einer Multithreaded-Web-Applikation). Nachdem ich mich erst seit ca. 2 Jahren mit Eclpse beschäftige wird es wohl auch noch einige Features geben, die ich noch nicht entdeckt habe (war bei VC genauso).

ZX

----------

## Voltago

Mein IDE-Tip: Netbeans 4.0 oder Eclipse 3.1pre5 (Achtung: muß mit JDK 1.4.2.x gebaut werden!) mit Sun's JDK 1.5.x. Angenehm flott.

----------

## Ragin

@ZX-81:

Wenn du dich mit Eclipse besser vertraut machen willst schau dir mal folgende Bücher an:

http://www.terrashop.de/89864282A/artikel.php

http://www.terrashop.de/44622865A/artikel.php

Ich habe noch das alte Eclipse 2 Buch, was aber auch recht gut ist. Da tauchen teilweise Funktionen auf, die man so gar nicht vermutet und die einem das Programmiererdasein etwas erleichtern.

----------

## LockeAverame

Noch etwas zum Thema Performance:

Java übersetzt code relativ schnell in bytecode unter anderem deswegen weil viele Optimierungen einfach ausgespart werden (zB Inter-Prozedurale-Optimierung, Dead Code Elimination oder Loop Unrolling). Deshalb muss der Programmierer bei Java meist stärker auf Optimierungen achten, muss sich allerdings dabei weniger um Architekturspezifika kümmern.

Dass die JVM dann den Bytecode optimal auf die darunter liegende Maschine übersetzt ist auch nur teilweise richtig. Autovektorisierung und optimale Nutzung der vorhandenen Ressourcen würde zuviel Rechenzeit in Anspruch nehmen, als dass sich das für den Bytecodeinterpreter lohnen würde. Nur Methoden/Klassen mit hoher Nutzfrequenz werden dauerhaft compiliert und im speicher vorrätig gehalten. Kann natürlich sein, dass sich da was geändert hat, aber ich glaube nicht.

Wenn man C/C++ Code mit etwa ähnlichen Optimierungen übersetzen würde wie es Java bietet, dann geht das übersetzen auch recht flott. Und mit "make" ist man auch das ständige rebuilden aller Object-Dateien los.

Meine Erfahrungen mit Eclipse sind eher zäher Natur, was allerdings auch an dem Frameworkoverhead von Eclipse liegt sowie dessen enorme (durchaus sehr praktische) Funktionalität.

Meine Erfahrungen mit einigen numerischen Programmen unter Java verliefen hingegen recht positiv. In der Regel läuft Java relativ flott, wenn man wenig Taskswitching in den Programmen hat (zB nicht massig zwischen verschieden Threads wechselt). Der Speicherverbrauch ist jedoch immer noch ein recht großes Problem. Bessere Optimierungen seitens des Java Compilers würde ich mir wünschen, auch wenn dann der Compilierprozess sich dann mehr Zeit genehmigt.

----------

## tex

Hi,

die Startzeit von Java ist langsamer, als die von C/C++ nativen Programmen. Dafür kann durch entsprechende Optimierungen die Ausführungsgeschwindigkeit schneller sein. Bei GUIs ist das wieder was anderes. Swing und Co sind nicht sonderlich schnell.

.NET hingegen läuft auf ähnliche Weise wie Java. Jedoch habe ich bereits Benchmarks gesehen, in denen .NET unter Windows um einiges schneller ist, als z.B. Java. Mono ist noch relativ langsam.

Gruß

Mike

----------

## tex

Achja: Hierauf möchte ich noch hinweisen:

http://java-gnome.sourceforge.net/cgi-bin/bin/view

Gruß

Mike

----------

## ro

mir sind keine nahen details bekannt und hab mich damit nicht eingehend beschäftigt (weil mich .NET so kalt lässt wie MS Win 3.11), aber soweit ich weiß hat Java eine weitaus sichere Architektur und ist um einiges schneller...

wollte auch nur meinen Senf dazugeben  :Wink: 

----------

## return13

aus diesem Thread ist doch mal wieder was ganz positives geworden, es hat stark dazu beigetragen das ich mich mal wieder mit Java beschäftige, und diese Gnome inteplentierung find ich klasse - gutes flash demo...

----------

## LockeAverame

Glaube für kde gibt es da auch nen gutes Binding, hab noch nicht damit gespielt, wäre aber ein Blick wert.

----------

