java oder lieber C#

[kara_lahana]

ich kann C.
Seit lange habe ich absicht, irgendwann richtig mit Java anzufangen.
Jetzt überlege ich mir,ob ich lieber C# lernen sollte.
ich habe nämlich gehört, dass C# viel schneller als java ist.

was haltet ihr davon?

 

[Anubis]

Ich kenn mich da zwar nicht so ganz aus, aber ich glaub, dass C# schneller ist, weil Java im Prinzip auf C basiert. Aber ich finde Java einfacher, weil man nicht immer so viel includen muss. In Java reichen ein paar Imports und du hast alles Nötiges.
(Stimmt das dass man in C relativ viel includen muss? Ich kann kein C, hab aber mal damit angefangen und dann aufgehört)

 

[kara_lahana]

cha !!

ich bin eigentlich auch neugrieg ander nach und vor teile von #c ?

 

[Koravel]

Ich finde es etwas ungeschickt, diese Frage in ein auf Java spezialisiertes Board zu schreiben :wink:
Ich denke das ist natürlich ganz deine Entscheidung, wobei ich Plattformunabhängigkeit dem geringen Geschwindigkeitsgewinn vorziehen würde.

Vor allem, wenn man bedenkt, dass Linux immer stärker wird.

 

[intruder]

Ich kenn mich da zwar nicht so ganz aus, aber ich glaub, dass C# schneller ist, weil Java im Prinzip auf C basiert.

Das ist nicht ganz die richtige erklärung. Du kannst nicht sagen, daß ein Golf 5 langsamer ist als Golf 4, weil der 5er auf dem 4er basiert. Die Ursache liegt ganz woanders.

C Programme werden direkt in Maschinensprache Kompiliert. Der Rechner bzw. Prozessor kann dann das Zeug dann direkt verarbeiten. Die Programme werden daher schneller ausgeführt sind aber Plattformabhängig d.h. dein Prog läuft entweder nur auf Windows oder nur Linux oder nur Mac, je nachdem für welche Platform du es kompiliert hast.

Java Programme werden in Bytecode übersetzt, der für alle Platformen gleich ist d.h. du kannst das gleiche Programm auf jeder beliebigen Platform laufen lassen.
Das ist ja klasse sagst du jetzt sicher.

Ja das ist es. Leider hat die sache aber einen kleinen Hacken.
Der Prozessor versteht den Bytecode nicht!

Toll! Und wozu dann Java? Was soll ich damit, wenn es nicht auf meinem Rechner läuft? - denkst du jetzt vielleicht.

Hym ... mal schauen. Wie kriegen wir es hin, daß unser Prozessor Bytecode versteht?

Ganz einfach, wir organisieren jemanden der Bytecode versteht und der soll es unserem Prozessor übersetzen.

Dieser jemand ist die JVM (Java Virtual Machine).
Es ist ein Stück Software oder besser gesagt ein Softwareprozessor den man ganz normal auf jeder Platform installieren. Die JVM verarbeitet den Bytecode und erklärt unserem Prozessor was er machen soll.

Dieser umweg über die Software kostet Zeit.
Dies ist der Grund dafür, dass Java langsamer ist als C.

Dafür ist es in Java einfacher Fehler zu vermeiden.
Prozesse die bei C von Hand gemacht werden müssen, wie z.B. das vernichten nicht mehr benötigter Objekte die Speicherplatz belegen, werden bei Java automatisch erledigt.

Wenn man also kein Vollprofi in C ist, kann es sein, dass die eigenen Progs in C dennoch langsamer sind als die gleichen Programme in Java, weil man einige Bugs reingehauen hat.

Hängt also alles davon ab, was du machst und wie gut du es machst

 

[Guest]

Ich finde es etwas ungeschickt, diese Frage in ein auf Java spezialisiertes Board zu schreiben :wink:
Ich denke das ist natürlich ganz deine Entscheidung, wobei ich Plattformunabhängigkeit dem geringen Geschwindigkeitsgewinn vorziehen würde.

Vor allem, wenn man bedenkt, dass Linux immer stärker wird.

cha!!! Wenn ich dies Frage bei eine forum von c# geschmiesen hätte,hätten die schreiben, dass c# von himmel gefallen ist und so

i wanna kritik !!!!!!!! ???:L

ich brauche gründe java zu lernen,obwohl es c# gibt!

 

[Manfred]

Bin mir zwar nicht sicher, aber läuft das bei C# nicht auch so, dass ein Interpreter benötigt wird??

Nochwas für Java:
Die ganze Mobile Technologie baut darauf

 

[Calamitous]

kurz gefaßt C# funktioniert ähnlich und hat damit die gleichen "Geschwindigkeitsnachteile" wie Java gegenüber von C.
Also C++ werden wahrscheinlich beide nie einholen. Der Vergleich der beiden zueinander ist eine Sache mit denen man endlos Bücher füllen könnte. Aber sagen wir doch einfach beide sind im schnitt zirka gleichschnell. C# hat halt den Nachteil das es Systemabhängig ist (dank MS.... :autsch: ansonsten könnte auch C# unabhängig sein)

 

[StarSeven]

Mal eine Frage, passt hierhin glaub ich.
Durch Just-in-Time Compiler soll Java nichtmehr viel langsamer als C++ sein.
Stimmt das?
Wieviel schneller ist eigentlich C/C++ noch?

 

[Roar]

java ist im moment nicht allzu schnell. das bessert sich aber immer weiter vor allem mit der JRE 1.5, sodass Java programme shcon fast an die geschwindigkeit eines c++ programms reinreichen können. c# wird auch nicht in OP code kompiliert sondern ind die MSIL die dann ein interpreter ausführen darf Java ist vor allem zu empfehlen da, wie shcon gesagt, es im Mobile bereich sehr of tverwendet wird und in zukunft eine große rolle spielen wird wenn jetzt so geile sachen wie UMTS kommen und so, außerdem weil java auch sehr oft im internet verwendet wird, auf servern sowie auf webseiten und so... ich dagegen kenne kein spezielles einsatzgebiet für c#. naja vielleicht serveranwendungen. dazu kommt noch dass kaum einer den .net interpreter hat, bzw. sich runterlädt. bei java ist es anders, da es ja shcon standartmäßig bei den betriebssystemen dabei ist ( bei linux, Mac OS, Solaris etc.) und da die browser die JRE schon beinhalten oftmals.

achja: java ist nicht von Microsoft, also ein sehr großer vorteil c# gegenüber.

 

[Reality]

Hi,

Dieser umweg über die Software kostet Zeit.
Dies ist der Grund dafür, dass Java langsamer ist als C.

nicht nur wegen dem. Der Carbage Collector ist sicher eine nette Idee. Jedoch frisst er Speicher und Rechenzeit.

Liebe Grüße
Reality

 

[bygones]

Der Carbage Collector ist sicher eine nette Idee. Jedoch frisst er Speicher und Rechenzeit.

Deswegen weglassen ?? Ne...
Außerdem kannst du mit JVM Argumenten den Collector ziemlich beeinflussen !!!

http://java.sun.com/docs/hotspot/gc1.4.2/
http://java.sun.com/docs/hotspot/

Durch Hotspot wurde Java schon viel schneller geschaffen - was scheinbar in 1.5 noch verstärkt wurde !

PS: Außerdem ist noch der größte Performance Killer der Programmierer :bae:

 

[Reality]

Von weglassen war nie die Rede. Ich habe nur den Nachteil genannt. Trotzdem wäre es mir ohne lieber.

Liebe Grüße
Reality

 

[bygones]

also lieber Speicher voll laufen lassen anstatt ein bisschen langsamer zu sein ?! ok...

 

[Reality]

Oh mann, was du wieder rausinterpretierst. :roll:
C und andere Sprachen kommen ohne Garbage Collektor auch zu recht. Dort macht man es eben manuell, was auch schneller ist und weniger Speicher verbraucht.

Liebe Grüße
Reality

 

[Roar]

ja und das ist dann auch der grund wieso der speicher dann zugemüllt wird wen man nicht richtig programmiert, das ist dann auch der grund dass das programm ab und zu mal abstürtzt wenn man nicht richtig programmiert. ich finde es wesentlich riskanter einfach so im speicher rumzufummeln als das jemand anderen übernehmen zu lassen.

 

[Reality]

Man sieht und lernt dazu...
Der Programmierer wird schon merken, dass der Speicher voll ist (was wohl eher bei größeren Programmen zutrifft) und den Fehler beheben.

Liebe Grüße
Reality

 

[Grizzly]

Oh mann, was du wieder rausinterpretierst. :roll:
C und andere Sprachen kommen ohne Garbage Collektor auch zu recht. Dort macht man es eben manuell, was auch schneller ist und weniger Speicher verbraucht.

Liebe Grüße
Reality

Das die manuelle (also eigenhändige) Speicherverwaltung schneller ist, ist klar. Bloss kämpfen damit auch viele C/C++ Programme mit Memory-Leaks, da es halt sehr schwierig ist, diese Speicherverwaltung als Programmierer 100% hinzubekommen (ich spreche da aus eigener Erfahrung).

Allerdings muss man fairerweise auch sagen: "Memory-Leaks" bekommt man auch in Java hin. Man muss nur irgendwelche Objekte referenzieren und vergessen, diese Referenzen wieder auf null zu setzen. Der Garbage Collector denkt sich dann, dass das Objekt noch benötigt wird und gibt den Speicher nicht mehr frei.

Trotzdem ist die Anfälligkeit bei C/C++ Programme deutlich höher, als bei Java Programmen.

 

[Beni]

Allerdings muss man fairerweise auch sagen: "Memory-Leaks" bekommt man auch in Java hin. Man muss nur irgendwelche Objekte referenzieren und vergessen, diese Referenzen wieder auf null zu setzen. Der Garbage Collector denkt sich dann, dass das Objekt noch benötigt wird und gibt den Speicher nicht mehr frei.

:?:

Der GC ist in der Lage "Referenz-Kreise" von Objekten zu erkennen (die in den Hauptthreads nicht mehr benötigt werden). So einfach kannst du ihn nicht überlisten :wink:

 

[Grizzly]

[...]So einfach kannst du ihn nicht überlisten :wink:

Es gibt ja auch nicht darum den GC zu überlisten, sondern das auch in Java Programmen sich Fehler einschleichen können, die zu Memory-Leaks führen.

Im Buch Effektiv Java programmieren ist dazu ein nettes kleines Beispiel:

import java.util.EmptyStackException;

// Finden Sie das "Speicherleck"?
public class Stack {
	private Object[] elements;
	private int size = 0;
	
	public Stack(int initialCapacity) {
		this.elements = new Object[initialCapacity];
	}
	
	public void push(Object e) {
		ensureCapacity();
		elements[size++] = e;
	}
	
	public Object pop() {
		if (size == 0) throw new EmptyStackException();
		return elements[--size];
	}
	
	/**
	 * Schaffe für mindestens ein weiteres Element Platz,
	 * indem du die Kapazität jedes Mal, wenn das Array
	 * wachsen muss, ungefähr verdoppelst.
	 */
	private void ensureCapacity() {
		if (elements.length == size) {
			Object[] oldElements = elements;
			elements = new Object[2 * elements.length + 1];
			System.arraycopy(oldElements, 0, elements, 0, size);
		}
	}
}