C# - fix oder nicht
-
C# ist absolut nicht zu empfehlen wenn man auf Performance angewiesen ist. Das einzige was ich dieser Sprache abgewinnen kann ist die Library die Microsoft bei Visual C# mitliefert. Die ist schön in Namespaces gegliedert (nicht so ein Durcheinander wie die MFC) und enthält ein paar gute Klassen. Ansonsten reizt mich diese Sprache nicht. Die Punkte die mich am meisten stören:
- Dass viele Leute jeden Mist auf .Net portieren wollen (weil das ja so modern ist). Das sind auch meistens die Leute die mit dem Kickboard zur Arbeit fahren obwohl sie zu Fuß schneller wären.
- Schlechte Performance.
- Unnötige Kapselung der main-Funktion in eine Klasse.
- switch auf strings etc. (ganz nett aber lahm und kein richtiges switch wie in C++).
- Wird nicht in Maschinencode übersetzt und ist dann auch noch nichtmal vollständig portabel.
Wem's reicht ok aber ich werde frühestens dann damit Programme schreiben wenn es ausgereift ist.
-
Ich werde wohl um einen kleinen Performancetest nicht herumkommen. Mal sehen, wie gross der Unterschied wirklich ist. Würden Euch die Ergebnisse auch interessieren?
-
MaSTaH schrieb:
C# ist absolut nicht zu empfehlen wenn man auf Performance angewiesen ist.
Das kann ich in dieser Pauschalität nicht bestätigen.
Ich habe mal einige kurze Konsolenprogramme verglichen. Nichts wildes, nur ein paar Berechnungen und Stringoperationen.
Native C++ (MSVC 7.1) war nur ca. 10% schneller als C#, welches wiederum etwa 5% schneller war als Native C++ (MSVC 6) (jeweils Release-Builds).
Ich denke, die schlechte Performance ist weniger ein Problem der Sprache als der wenigen kompetenten Programmierer. Man kann auch in C++ langsame Programme schreiben.
-
C# muss prinzibedingt langsamer sein:
- wegen der Kompilerung in MSIL statt Native Code, die "wahre" Konpilerung findet also erst nach dem Start statt, ähnlich P-Code bei VisualBasic.
- wegen aller möglichen nicht vollständig abschaltbaren debugging features (die im Hintergrund natürlich auch Rechenleitsung beanspruchen)
- ständig werden überprüfungen für zugriffsberchtigungen für z.B. Speicherbereiche oder Dateipfade gemacht -> erhöht Sicherheit vor Viren, Trojanern und unerlaubten Eingriffen von außen ins Programm -> aber Sicherheit kostet eben... Performance.
-
versucht es mal mit dem Mono-Compiler, soll sehr fixen code generieren (schneller als von m... wie weit das stimmt weiß ich nicht, hab ich gesagt bekommen von leuten die seit mono total auf c# abfahren.
http://www.go-mono.com/c-sharp.html
rapso->greets();
-
Ok, ich habe jetzt gemessen, das C# ~2,6 mal soviel Zeit für eine allgemeine Filterberechnung benötigt, als es C++ bräuchte. Es ist also nicht ganz so schlimm, wie man aus einigen Kommentaren hier rausliest. Bei Gelegenheit teste ich es auch mal mit dem Mono-Compiler. Kann der denn auch die ganzen Forms Sachen, so das ich ohne grosse Aufwand dahin umstellen kann?
-
der sollte ganz .NET unterstützen und meine kolegen arbeiten zuhause auf linux damit und dann in der arbeit wohl mit dem m$ kram, scheint zu laufen, aber 100%ig sicher bin ich mir nicht!
rapso->greets();
-
MFK schrieb:
Native C++ (MSVC 7.1) war nur ca. 10% schneller als C#, welches wiederum etwa 5% schneller war als Native C++ (MSVC 6) (jeweils Release-Builds).
Du hast doch sicher erst nach dem Prorammstart gemessen, oder. Ich kenne die genauen Abläufe nicht, aber ein MSIL-Programm muss ja auch irgendwann mal (zumindest) teilweise als Maschinencode im Speicher liegen um den Code auszuführen (ich glaube nicht, dass C# eine reine Interpretersprache ist). Dann ist es fast genau so schnell wie anderer Maschinencode. Aber das ganze muss ja erst in Fahrt kommen. Mach mal eine ellenlange Berechnung über mehrere Funktionen verteilt (mit Rekursionen etc.) und setz' dich mit der Stoppuhr daneben von Programmstart bis Terminierung. Der Unterschied solte merkbar sein.
MFK schrieb:
Ich denke, die schlechte Performance ist weniger ein Problem der Sprache als der wenigen kompetenten Programmierer.
Und davon gibt es IMHO zu viele als dass man denen noch langsame Sprachen in den Rachen werfen sollte. Stell dir mal vor du brauchst bei deinem Job Spezialsoftware (die du aufgrund mangelnder Fachkenntnisse in dem Gebiet nicht in absehbarer Zeit selber schreiben kannst, z.B. Rohrnetzplanung o.ä.) die nur ein Anbieter herstellt. Dieser hat nur schlechte Programmierer und dann auch noch C#-Applikationen im Programm. Du wirst dich schwarz ärgern (oder freuen, je nachdem ob du am Umsatz beteiligt bist oder nicht
) weil du jedesmal einen Kaffee holen kannst wenn du was per Drag&(Wait&)Drop in dein Fenster einfügst.
-
Das Problem mit den schlechten Programmierern stellt sich bei uns nicht ;). Und einmalige Einbussen beim Start des Programms kann ich auch vernachlässigen, es geht mir nur darum, das schlechte Responsiveness den Workflow der Leveldesigner kaputt macht.
-
rapso schrieb:
versucht es mal mit dem Mono-Compiler
Das das Ding leider weder meinen kleinen Bench kompiliert noch das MS Kompilat ausführt, kann ich jetzt nicht sagen wie es sich verhält. Habe leider im Moment nicht so recht Zeit, das Ding lauffähig zu bekommen.
-
C'T Leser wissen mehr. In der aktuellen Ausgabe gits den ersten Teil eines C++, J, C#, Delphi Effizienztests.
mfg
freigeist
-
Na und die sagen mir bestimmt, wie gut meine speziellen Algos auf den Plattformen laufen und wie ich in C# meine Performance optimiere. Was bringt mir das wenn die ein paar Testsuiten laufen lassen, aber die brauche ja auch was um ihre Zeitung vollzusschreiben...
-
ich code normalerweise in C/C++/MFC und DirectX (7) <- schande, die 7
meine meinung über c# iss eigentlich ganz gut.
mir gefällt die sprache wesentlich besser als java, nur die Performance......
aber, hat java eine performance.... ?????zur beruhigung - ich bleibe bei mfc (nicht bei c/c++ - bessere performance) - aber klassen !!!!
und daher kann ich auch leute verstehen, welche in c# coden
-
Ahja, eine klare Aussage.
