Delphi am "Ende"?

[Assarbad]

http://www.codeproject.com/Surveys/1...velop-des.aspx

Delphi nur auf dem vorletzten Platz. Wobei die Frage ist, inwieweit die Seite (die ich mehr dem C/C++/C#-Lager zuordnen würde) vielleicht der Grund für dieses "Zerrbild" (?) ist.

[Daniel]

Mit Blick auf Cocoa auf dem letzten Platz denke ich, dass die Zielgruppe wirklich zu C++/C#-lastig ist.

[Bernhard Geyer]

Zitat von Assarbad:

http://www.codeproject.com/Surveys/1...velop-des.aspx

Delphi nur auf dem vorletzten Platz. Wobei die Frage ist, inwieweit die Seite (die ich mehr dem C/C++/C#-Lager zuordnen würde) vielleicht der Grund für dieses "Zerrbild" (?) ist.

codeproject wäre ein der letzten Seiten die ich bei Delphi/Pascal-Fragen besuchen würde ...
Im Delphi-Forum gibt es gerade mal 188 Posts.

[Assarbad]

Sorry, daß ich das nochmal herauskrame - der Aspekt Geschwindigkeit wurde hier ja zuvor noch nicht so stark angesprochen. Vielleicht hat Embarcadero ja auch einen Kommentar zu dem Thema.

Hier mal ein Vergleich des Scimark Benchmarks (auch auf die Kommentare achten):

http://delphihaters.blogspot.com/201...nd-delphi.html

Es gibt da verschiedene Versionen, es ist wohl ein neuerer Port im VCS. Einerlei, die Delphi-Versionen scheinen irgendwie immer ziemlich schlecht abzuschneiden. Ihr könnt die Tests ja mal selber laufen lassen. Wäre ohnehin interessant das noch mit anderen Compilern zu probieren ...

Ich weiß, Performance ist nicht in allen Anwendungen wichtig, aber das Ergebnis ist doch (leider) sehr eindeutig.

PS: Ich weiß, daß der Name des Blogs nicht sonderlich vertrauenerweckend ist, aber man kann die Tests ja, wie gesagt, selber laufen lassen und vergleichen.

[Namenloser]

Es mag schon stimmen, dass andere Compiler, vor allem im Bereich C/C++, besser und aufwändiger optimieren als Delphi. Das sind aber im Gegensatz zu Delphi praktisch immer Multipass-Compiler, mit dem Nachteil, dass der Kompiliervorgang auch deutlich länger dauert. In kaum einer anderen Sprache kann man so schnell mal eben Code schreiben, kompilieren und testen wie in Delphi.

Daran sieht man eben, dass Delphi mehr auf RAD ausgelegt ist, als auf hohe Runtime-Performance.

Andererseits hängt die Geschwindigkeit natürlich auch immer sehr stark von der Implementierung ab, deshalb sind solche Tests auch immer so eine Sache...

Mir persönlich hat die Performance unter Delphi eigentlich immer gereicht. Performacekritische Funktionen optimiere ich eh von Hand.

[Lemmy]

Super dass es hier wieder weiter geht... Die Atom-Geschichte wird langsam langweilig...

Delphi lebt! Immerhin werden wieder neue Bücher veröffentlicht... http://blog.marcocantu.com/blog/delp...ry_jensen.html

Dennoch: Danke Asserbad für den Link...

[Assarbad]

Zitat von Lemmy:

Delphi lebt!

Sonst wäre die DP ja auch tot. Aber ich wollte deswegen auch kein neues Thema aufmachen und dieses hier paßte und war nicht zu alt ...

[Phoenix]

Zitat von NamenLozer:

Das sind aber im Gegensatz zu Delphi praktisch immer Multipass-Compiler, mit dem Nachteil, dass der Kompiliervorgang auch deutlich länger dauert.

Nunja, Multipass-Compiler haben allerdings auch ihre Vorteile. So geniale Sachen wie partial classes lassen sich eben nur dann umsetzen, wenn der Compiler auch später (d.h. wenn er an einem anderen File ankommt) noch eine Klassendefinition anpassen kann, und den Code dann in einem zweiten Durchgang fertig kompiliert.

Gerade bei Delphi sollte das noch nichtmal so sehr auf die Performance niederschlagen, da sich der erste Durchgang auf die Interface- Sektion und der zweite auf die implementation-Sektion beschränken kann. Es wäre als in Summe tatsächlich nur ein Durchlauf, der aber zweigeteilt wäre.

[Robotiker]

Zitat von NamenLozer:

Es mag schon stimmen, dass andere Compiler, vor allem im Bereich C/C++, besser und aufwändiger optimieren als Delphi. Das sind aber im Gegensatz zu Delphi praktisch immer Multipass-Compiler, mit dem Nachteil, dass der Kompiliervorgang auch deutlich länger dauert. In kaum einer anderen Sprache kann man so schnell mal eben Code schreiben, kompilieren und testen wie in Delphi.

Daran sieht man eben, dass Delphi mehr auf RAD ausgelegt ist, als auf hohe Runtime-Performance.

Ich hatte ja schon mal in einem anderen Thread geschrieben, es gab mal ein Borland Produkt, wo man den Unterschied schön sehen konnte. Der C++ BuilderX enthielt in den größeren Versionen den Compiler aus dem C++ Builder 6, den Intel Compiler und den MingW (GNU Compiler für Windows) und konnte den Compiler aus dem parallel installierten Visual Studio 2003 verwenden.

Man konnte also in einer IDE den gleichen Code mit vier Compilern übersetzen. Die Unterschiede bei der Übersetzungszeit waren teilweise dramatisch. Ich kann mich an ein Projekt erinnern, da brauchte der Borland 16 Sekunden und der GNU knapp 3 Minuten.

Die Geschwindigkeit des erzeugten Codes war praktisch immer in der Reihenfolge Intel, MS, GNU, Borland. Aber sehr abhängig von dem, was da gerechnet wurde. Bei numerischen Sachen konnte sich der Intel extrem absetzen, Borland fiel weit zurück. Bei Stringoperationen (z.B. XML) praktisch kaum ein Unterschied zwischen MS und Intel, GNU und Borland gemeinsam etwas abgeschlagen.

Grundsätzlich gilt das heute zwischen C++ Builder XE und Visual Studio 2010 immer noch, alles was viel rechnet, wirkt mit dem bcc32 übersetzt etwas träge.

[HeikoAdams]

Aus meiner Vergangenheit weiß ich, das der Sybase PowerBuilder das Problem relativ elegant gelöst hat: zum Entwickeln und testen gibt es ein schnelles Compilieren ("Build"), bei dem nur die Änderungen neu übersetzt werden und für Releases ein gründliches Compilieren ("Full rebuild"), bei dem der komplette Sourcecode neu übersetzt wird. Vielleicht wäre das in Verbindung mit einem hochperformanten Multipass-Compiler eine Option für Delphi.