Alle .NET-IDEs: Langsam!!

[Counterfeit]

Also ich habe schon mal einen Benchmark gesehen und jetzt ohne zu lügen neben C++ war C# auf Platz 2, Platz 3 war Delphi und Platz 4 war Visual Basic. Das war ein Programm womit man Fraktale oder wie die heißen erstellt werden. Und da lag die FPS von C# nur 20 FPS weniger als in C++. Besonders gut kann man die Programm testen, indem man sortier Algorithmen benutzt. Und mit dem Framework 2.0 wird .NET nochmal kräftig einschlagen, weil da enorme Features dabei sind.

[Code Poet]

Also wir haben heute gebenchmarkt.Die Codelogik (Delphi und C#.NET) war dieselbe.

Die C#-Anwendung war erwartungsgemäß etwas zeitintensiver beim Starten (wir haben ein paar Bilder auf die Formen gesetzt). Gemessen haben wir allerdings erst, als die Apps oben waren.

Wir kamen zu folgenden Ergebnissen:

Visual C# liegt klar im Vorteil, wenn es darum geht, Formulare (neu) zu zeichnen bzw. API-Aufrufe in Windows zu bewerkstelligen (ca. 16% schneller). Das gilt allerdings nur auf Windows-XP-Rechnern. Auf Windows 2000 war es schon schwierig, das .NET-Framework vernünftig ans Laufen zu kriegen, weil nebenher noch eine Siemens OPC-Installation lief.

Bei Aufgaben wie sortieren von Pointerlisten und Stringverarbeitungen liegen Delphi und VC# fast gleich auf (nur unter XP getestet, Delphi war 2% schneller).

Danach kamen ein paar CPU-intensive Rechenoperationen (FP), bei denen Delphi seinen MS-Gegner deutlich geschlagen hat (23% schneller).

Bei Multithreading-Aufgaben kam C# dann wieder etwas in Gang, bzw. Delphi ins Schwitzen... der Abstand verkürzte sich auf ca. 19%.

Eine weitere Achillesferse von .NET sind wohl ältere Systeme. Auf NT4 läuft das Framework sowieso nur mit Servicepack 6 und die Anwendungen, selbst wenn simpel mehr schlecht als recht, auch wenn die CPU an sich flott ist. Windows 95 und .NET arbeiten gar nicht zusammen, wohingegen die Delphi-Exe auch hier anstandslos ihren Dienst tut.

Zugegeben W95 benutzt sowieso kaum noch wer, also wäre das ja nicht weiter schlimm, aber zumindest NT4 ist noch in vielen Rechnern im Einsatz, besonders in Firmen, die schwere Industriegeräte betreiben.

Auch eine schwache CPU können Delphi-Apps besser ab als C#.NET. Auf einer 500MHz-Schüssel XP zu installieren kann an sich schon abenteuerlich sein :-), aber es läuft immerhin. 64MB RAM sind allerdings auch nicht die Welt, aber hier ist die Delphi-Anwendung um 48% schneller als die C#-Anwendung gleichen Inhalts.

Fazit: Native Delphi-Apps sind im Low-Level-Bereich schneller und sind auch nicht böse, wenn man ein älteres System, einen älteren Rechner oder beides hat. C# ist klar im Vorteil, wenn es um Anwendungen geht, die hauptsächlich mit der Windows-API zusammenarbeiten, also die meisten Desktop-Anwendungen. Wer Signal- oder Prozessvisualisierungen entwickelt dürfte also mit Delphi immernoch besser dran sein. Auch wissenschaftliche Programme sind wohl eher ein Fall für unsere Orakelstätte....

Bunte Oberflächen mit Datenbankabfragen und ohne komplexere mathematische Operationen entwickelt man allerdings besser mit .NET, es sei denn, man will sie auch auf einem richtigen Betriebssystem einsetzen!

[Guybrush Threepwood]

Ganz sicher nicht. Nicht als .NET-Programm.

Doch da gibt es irgendeine Anwendung mit der du eigenständige Executables erstellen kann. Diese laufen dann ohne Framework, wie genau das funktioniert und welche Vor- oder Nachteile es dabei gibt weiß ich allerdings nicht.

Ich kann aber, wenn ich dran denke, am Dienstag mal meinen Ausbilder fragen wie der Befehl heißt:)

[Code Poet]

Sicher bin ich mir da bei VS.NET nicht. Beim C#-Builder ist es ein Compilerschalter im Code.

[Counterfeit]

Das glaub ich kaum, das es da einen Befehl gibt, den viele Firmen arbeiten bereits an Tools, womit man solche *.exe Dateien erstellen kann und dort werden die Frameworkdlls eingebunden die man auch im Projekt benutzt.

[Code Poet]

Es gibt eine Option bzw. einen Compilerschalter! Im Prinzip macht man ja nichts anderes, als die DLLs statisch zu linken (deswegen dann auch diese Hammerexen, ähnlich wie bei VB)!

[Counterfeit]

Mhh das währ mir neu

[Vampire]

[...]

Diesen Effekt kenne ich von Visual Basic 6.0. Die Execs waren nicht nur zumeist unverhältnismäßig groß, sondern auch gähnend langsam.

[...]

ähm, also bei mir sind die VB EXEn nie wirklich groß.

Arbeite zur Zeit an einem Programm für die Ligaverwaltung beim Sportschießen:

Hauptexe: 606.208 Byte

Ausgabeschnittstelle DLL: 36.864

Die DLL mit Grafiken und sonstigen Ressourcen ist allerdings sehr groß: 3.981.312

Da sind aber auch über 3 MB an Grafiken drin...

Und schnell ists auch, was die Datenbank halt hergibt...

Zum .NET Framework:

War nicht mal eine Aussage von MS das auch für Unix/Linux zu bauen???

Kann sein, dass das jetzt Wunschdenken von mir ist, aber ich meine da mal was gelesen zu haben.

[NoOneKnows]

Zum .NET Framework:

War nicht mal eine Aussage von MS das auch für Unix/Linux zu bauen???

Kann sein, dass das jetzt Wunschdenken von mir ist, aber ich meine da mal was gelesen zu haben.

Also von Micro$oft gibts nix. Aber andere haben sich die Mühe gemacht einen C#-Compiler für Linux zu schreiben. Nennt sich dann

Mono. Ist auch keine komplette Portierung des .NET Frameworks, sondern nur einiger Teile.

[geloescht_JesterDay]

ähm, also bei mir sind die VB EXEn nie wirklich groß.

Arbeite zur Zeit an einem Programm für die Ligaverwaltung beim Sportschießen:

Hauptexe: 606.208 Byte

Ausgabeschnittstelle DLL: 36.864

Die DLL mit Grafiken und sonstigen Ressourcen ist allerdings sehr groß: 3.981.312

Da sind aber auch über 3 MB an Grafiken drin...

Zu den Exe-Größen... VB EXEn sind klein, ja. Aber wenn du die VB EXE starten willst, brauchst du eine VBRuntime auf der Maschine, und die hat auch wieder einige MB. Diese Runtime ist nichts anderes als ein paar DLLs, die vom Programm beim starten eingebunden werden und die eben das "VB-Framework" ausmachen.

Delphi EXEn sind relativ groß (standardmäßig). Aus dem Grund, weil dort das "Delphi-Framework" immer in die Exe compiliert wird. Um eine Delphi EXE zu starten benötigst du nichts, ausser Windows als OS. Es ist aber auch möglich die EXE mit Runtime Packages zu erstellen. Das ist nichts anderes als es VB macht. Ergebnis: kleine EXE aber benötigt zusätzlich zur EXE eine weitere Installation.

Wenn du eine C-EXE nimmst ist die auch kleiner als eine Delphi EXE. Warum? Die C-Runtime ist bei Windows schon dabei. Du musst sie nicht extra installieren, aber sonst ist es kein Unterschied.

Die große Delphi-EXE hat gegenüber der kleinen VB-EXE einen Vorteil, nämlich das sie überall läuft. Stell die mal eine Autostart.exe auf einer CD vor, die mit VB erstellt wurde. Der Benutzer legt die CD ein und es kommt ne Fehlermeldung, dass die VB6Runtime.dll nicht gefunden wurde -.-

Bei C würde es genausoaussehen (große EXE oder nur mit Zusatzinstallation lauffähig) wenn nicht die Windowsentwicklung auf C aufgesetzt wäre.

Zum Aussterben von Delphi:

Seit D7 (als Beta) gibt es Delphi.Net. also Delphi Code wird in eine .Net IML umgesetzt. D8 war das erste "richtige" Delphi.Net und mit D9 (wurde letztens auf der BorCon vorgestellt, also in einer sehr frühen Phase) soll sich da einiges gebessert haben. C#-Builder, Delphi.Net und Delphi.W32 in einem Programm.

Ich bin auch mmit D7 sehr zufrieden und die 2 D8 Lizenzen die wir hier haben werden von keinem eingesetzt. Aber die Vorschau auf D9 sah schon recht gut aus.

http://info.borland.com/media/shockwave/delphi2005/d2005sneak.html

Was is eigentlich sagen wollte: Trotz .Net wird Delphi nicht aussterben. Ich habe mit .Net auch nix am Hut (und hoffe es bleibt auch so), aber so trüb würd ich nciht in die Zukunft sehen (also nur auf die Sprache bezogen).

[xerves]

VB6 ist nicht langsam wenn man gut programmiert. benutze es in der Firma nur und alle unsere Programme sind darauf entwickelt.

Klar ist es langsamer als C aber dafür viel schneller was das entwickeln angeht. VB6 wird größtenteils immernoch eingesetzt weil es einfach ist und sehr gute ergebnisse liefert

[Vampire]

Zu den Exe-Größen... VB EXEn sind klein, ja. Aber wenn du die VB EXE starten willst, brauchst du eine VBRuntime auf der Maschine, und die hat auch wieder einige MB. Diese Runtime ist nichts anderes als ein paar DLLs, die vom Programm beim starten eingebunden werden und die eben das "VB-Framework" ausmachen.[...]

Hm, gebe zu, daran hab ich nicht gedacht...

[geloescht_JesterDay]

Soweit ich weiß wird Kylix nicht mehr weiter entwickelt(Ich lasse mich da gerne belehren), weil zwar alle gesagt haben:"Hey toll, Delphi unter Linux!", aber nacher keiner das Ding gekauft hat bzw Programme für Linux geschrieben hat.

Ach ja...hab ich vergessen: Der Novell Client (für die Anmeldung am Novell Tree), also einer, für Linux wurde mit Kylix geschrieben und ist OpenSource.