C# - fix oder nicht

TGGC

Hat jemand schonmal die (wahnwitzige?) Idee gehabt sich mit C# ein paar Tools für seine Projekte zu schreiben. Nach einigen probieren finde ich ja: Das Entwickeln geht recht fix, aber die Ausführungsgeschwindigkeit leidet ziemlich.

Was habt ihr da für Erfahrungen und evtl. Workarounds?

nman

Ich musste mal ein paar Monate des schnöden Mammons wegen C# programmieren und um ehrlich zu sein bin ich froh dass ich das nicht mehr tun muss; ich mochte weder Syntax noch Leistungsmerkmale der Sprache.

Hast Du schon mal Delphi in Betracht gezogen? Das hat ziemlich viele Fans und dürfte mindestens genauso RAD-tauglich wie C# sein und die Performance ist wohl auch besser.

Kane

Ich habe nur mal versucht einen kleinen Filesplitter zuschreiben.
Die Performance war so mies, das ich das ganze Projket in die Tonne hauen
mußte.

TGGC

Alternativen für mich wären eigentlich eher reines C++ (dann z.b. mit MFC aber auch gegen WinApi hab ich nix) oder die langsamen Stellen in DLLs auslagern.

irgendwer hat doch quake 2(?) auf c# portiert und es läuft gut.

TGGC

na ja schrieb:

irgendwer hat doch quake 2(?) auf c# portiert und es läuft gut.

Das ist ja auch nicht so anspruchsvoll wie mein Tool, also wayne.

Walli

na ja schrieb:

irgendwer hat doch quake 2(?) auf c# portiert und es läuft gut.

Das "portierte" Quake 2 war auch wie gehabt in C geschrieben. Es wurden ein paar Modifikationen vorgenommen bevor man es in dem Managed-C++ Müll gewrappt hat. Das einzige in C# bei diesem Projekt ist ein kleines Zusatztool. Der ganze Code wird dann beim "kompilieren" AFAIK in die Zwischensprache (Microsoft Intermediate Language oder so ähnlich) übersetzt.

TGGC

Naja, ich hoffte eigentlich das einige evtl. noch Tipps kennen, um direkt in C# kräftig zu optimieren (und welche Geschwindigkeit somit letzendlich zu erreichen ist). Ich habe mich etwas mit der unsafe und fixed beschäftigt, was teilweise die Geschwindigkeit verdreifacht hat. Aber scheinbar haben alle hier, die es benutzten, so negative Erfahrungen, das sie C# gleich wieder haben sein lassen.

Walli

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.

TGGC

Ich werde wohl um einen kleinen Performancetest nicht herumkommen. Mal sehen, wie gross der Unterschied wirklich ist. Würden Euch die Ergebnisse auch interessieren?

MFK

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.

illuminator

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.

rapso

versucht es mal mit dem Mono-Compiler, soll sehr fixen code generieren (schneller als von m $) und angeblich hat es die sprache besser implementiert als 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();

TGGC

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?

rapso

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();

Walli

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.

TGGC

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.

TGGC

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.

freigeist

C'T Leser wissen mehr. In der aktuellen Ausgabe gits den ersten Teil eines C++, J, C#, Delphi Effizienztests.

mfg
freigeist

TGGC

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...