Delphi vs. C# vs C++

[mkinzler]

Zitat:

Zitat von luisk (Beitrag 1310380)

Zitat:

Zitat von mkinzler (Beitrag 1310365)

C# (2015) benötigt sogar etwas weniger als Delphi (16,6 Sekunden)

Das heißt, bei Dir läuft der Code in C# genauso schnell wie in Delphi, bzw. einen Tick schneller ?
Kann es sein, dass die Express-Edition von Microsoft nicht die volle Leistung bringt ?
http://www.chip.de/downloads/Visual-..._36594529.html

Ohne Ausgabe, mit dem Code in meinem Beitrag

[mkinzler]

Aber klarer Verlierer ist Delphi64 mit 104s.

[BUG]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1310385)

http://www.heise.de/artikel-archiv/c...el-Duesentrieb
http://www.heise.de/artikel-archiv/c...el-Duesentrieb

Vielen Dank fürs Raussuchen, so weit reicht mein Archiv leider noch nicht zurück. Werde mir noch überlegen, ob ich für nen 12 Jahre alten Artikel 3,50€ ausgeben möchte :shock:
Irgendwann muss ich mir mal das komplett-Archiv holen ...

[luisk]

Zitat:

Zitat von mkinzler (Beitrag 1310387)

Zitat:

Zitat von luisk (Beitrag 1310380)

Zitat:

Zitat von mkinzler (Beitrag 1310365)

C# (2015) benötigt sogar etwas weniger als Delphi (16,6 Sekunden)

Das heißt, bei Dir läuft der Code in C# genauso schnell wie in Delphi, bzw. einen Tick schneller ?
Kann es sein, dass die Express-Edition von Microsoft nicht die volle Leistung bringt ?
http://www.chip.de/downloads/Visual-..._36594529.html

Ohne Ausgabe, mit dem Code in meinem Beitrag

natürlich taugt mein Performande-Test was.
Die Frage ist doch nun:
Kann es sein, dass die Express-Edition von Microsoft nicht die volle Leistung bringt,
sondern von MS ausgebremst wird ?

mKinzler, Du hast ja wohl eine Vollversion von C#.
Kannst Du auch mal den Vergleich zur Express-Edition machen ?
Hier wäre eine:
http://www.chip.de/downloads/Visual-..._36594529.html

[mkinzler]

Hast Dzu exakt den gleichen Code getestet oder Deinen?

[Union]

Was ist jetzt genau das Ziel sowie die Aufgabenstellung dieser Untersuchung? Was willst Du mit den Ergebnissen tun bzw. erreichen?

[luisk]

Zitat:

Zitat von mkinzler (Beitrag 1310394)

Hast Dzu exakt den gleichen Code getestet oder Deinen?

ich habe genau deinen Code getestet und Delphi ist auch hier um den Faktor 10 schneller.

Ich habe aber nur die kostenlose Express-Edition von C#.
Damit stellt sich wie schon gesagt die Frage, ob die Express-Edition von Microsoft ausgebremst wird.

[vagtler]

Nein, wird sie nicht.

Dein Testverfahren ist schlicht und ergreifend nicht geeignet. Aber das haben ja schon andere hier in der Breite dargelegt.

[luisk]

Zitat:

Zitat von vagtler (Beitrag 1310397)

Nein, wird sie nicht.

Dein Testverfahren ist schlicht und ergreifend nicht geeignet. Aber das haben ja schon andere hier in der Breite dargelegt.

Hey,
wenn Du lesen könntest, hättest Du bemerkt, dass ich den Test von MKinzler auch durchgeführt habe !
Und mit der Express-Version läuft dieser Code auch nur mit 1/10 der Geschwindigkeit klar ?
http://www.chip.de/downloads/Visual-..._36594529.html
kannst die Version ja mal runterladen und testen !

[mkinzler]

Jetzt wird es komisch: Ich habe mal die urspüngliche VCL Version getestet, diese ist schneller als die Konsolenversion ust exakt gleich schnell wie die grafische C#-Version (16,8s) und unter 64Bit 17s

Delphi-Quellcode:

var li,lj,st,et:integer;
begin
        li := 0;
        lj := 0;
        st := GetTickCount;

            for li:=0 to 50000 do begin
               for lj:=0 to 1000000 do begin

                end;
                if (li mod 1000=0) then begin
                   button1.caption := inttostr(li);
                   button1.Update();
                end;
            end;
            Caption := IntToStr(GetTickCount -st);
end;

[luisk]

hab hier was gefunden:
https://msdn.microsoft.com/de-de/library/wx0123s5.aspx

So wechseln Sie schnell zur Debugkonfiguration oder zur Releasekonfiguration

• Wählen Sie auf der Symbolleiste Standard im Listenfeld Projektmappenkonfigurationen die Option Debuggen oder Release aus.

• Diese Symbolleiste ist in Visual Basic Express oder Visual C# Express nicht verfügbar. Sie können die Menüelemente Projektmappe erstellen (F6) und Debuggen starten (F5) verwenden um die Konfiguration auszuwählen.
---------------------------------------------------------
kann es sein, dass Visual C# Express kein Release erstellen kann ?
ich bekomme hier nichts rein:
C:\Users\User_1\Documents\Visual Studio 2015\Projects\ConsoleApplication1\ConsoleApplicati on1\bin\Release

[JasonDX]

Zitat:

Zitat von luisk (Beitrag 1310400)

hab hier was gefunden:
https://msdn.microsoft.com/de-de/library/wx0123s5.aspx

So wechseln Sie schnell zur Debugkonfiguration oder zur Releasekonfiguration

• Wählen Sie auf der Symbolleiste Standard im Listenfeld Projektmappenkonfigurationen die Option Debuggen oder Release aus.

• Diese Symbolleiste ist in Visual Basic Express oder Visual C# Express nicht verfügbar. Sie können die Menüelemente Projektmappe erstellen (F6) und Debuggen starten (F5) verwenden um die Konfiguration auszuwählen.
---------------------------------------------------------
kann es sein, dass Visual C# Express kein Release erstellen kann ?

Ich glaube du musst einfach die Projektmappe erstellen, um die Konfiguration auszuwählen.

Aber (nachdem die Frage ca. 30 mal gestellt und 30 mal ignoriert wurde): Was willst du denn erreichen? Was ist das Ziel des Tests?

[Sir Rufo]

Wo kann man die Express-Version von VS2015 denn herunterladen? Weiß das jemand zufällig? :mrgreen:

Nur mal so am Rande: Es gibt eine Community-Version von VS2015 (die ist vergleichbar mit der Pro) und die ist für bestimmte Entwicklerkreise kostenlos. Dazu sollte man aber nicht bei Chip schauen, sondern bei dem, der das Dingsbums baut. :roll:

[luisk]

Zitat:

Zitat von Sir Rufo (Beitrag 1310402)

Wo kann man die Express-Version von VS2015 denn herunterladen? Weiß das jemand zufällig? :mrgreen:

Nur mal so am Rande: Es gibt eine Community-Version von VS2015 (die ist vergleichbar mit der Pro) und die ist für bestimmte Entwicklerkreise kostenlos. Dazu sollte man aber nicht bei Chip schauen, sondern bei dem, der das Dingsbums baut. :roll:

http://www.microsoft.com/en-us/downl....aspx?id=46863
wird wohl die gleiche sein, wie bei chip

[Sir Rufo]

OMG
https://www.visualstudio.com/en-us/p...-editions.aspx
Augen auf, lesen, verstehen, downloaden, selber den Vergleich durchführen :roll:

[luisk]

So, habs jetzt gefunden:
Hauptmenu: Erstellen -> Konfigurationsmanager -> Release anwählen,
dann Start
C:\Users\User_1\Documents\Visual Studio 2015\Projects\ConsoleApplication1\ConsoleApplicati on1\bin\Release\ConsoleApplication1.exe

damit läuft das Programm unter C# Express als Release genauso schnell, wie unter Delphi.
Die Bedienung ist halt etwas umständlich. Bei der alten Version (2008) musste man nur "Starten ohne Debugging", dann war das Release da.
Bei Delphi läuft die Debug-Version so schnell, wie die Release-Version - oder sehe ich das falsch ?

[Daniel]

Zitat:

Zitat von luisk (Beitrag 1310406)

damit läuft das Programm unter C# Express genauso schnell, wie unter Delphi.

Das bedeutet, dass die Aussage aus Deinem Eingangsbeitrag Makulatur ist?

[pixfreak]

Zitat:

Zitat von luisk (Beitrag 1310400)

hab hier was gefunden:

• Diese Symbolleiste ist in Visual Basic Express oder Visual C# Express nicht verfügbar. Sie können die Menüelemente Projektmappe erstellen (F6) und Debuggen starten (F5) verwenden um die Konfiguration auszuwählen.
---------------------------------------------------------
kann es sein, dass Visual C# Express kein Release erstellen kann ?

EDIT: War zu langsam beim Threadlesen...


Hi,

klick mal mit der rechten Maustaste auf Deine Projektmappe im Projektmappenexplorer und wähle Konfigurations-Manager... Dort kannst Du auch ein Releasebuild auswählen...


VG Pixfreak

[luisk]

Zitat:

Zitat von Daniel (Beitrag 1310407)

Zitat:

Zitat von luisk (Beitrag 1310406)

damit läuft das Programm unter C# Express genauso schnell, wie unter Delphi.

Das bedeutet, dass die Aussage aus Deinem Eingangsbeitrag Makulatur ist?

Das wollte ich ja rausfinden,
die haben das Release mittlerweile etwas versteckt :thumb:

Das ursprüngliche Performance-Vergleichsprogramm passte auf jeden Fall.
Es läuft jetzt auch annähernd so schnell bei C# als Release, wie unter Delphi 6. Der Faktor 10 ist weg.

@Pixfreak
hab´s in #56 schon erwähnt
bei der alten Version 2008 war das nicht nötig, da reichte "Start ohne Debugging" dann war das Release da.

[luisk]

Programmiert überhaupt noch jemand Delphi,
oder sind alle zu Microsoft gewechselt ?

Wenn C# inzwischen genauso schnell oder schneller als Delphi ist ?

[Daniel]

Zitat:

Zitat von luisk (Beitrag 1310410)

Wenn C# inzwischen genauso schnell oder schneller als Delphi ist ?

Die überwiegende Menge an Performance-Problemen, die ich bei Kunden-Projekten bisher finden konnte, war nicht auf die Sprache bzw. deren Compiler zurück zu führen. Ich denke, dass das, was hier "gemessen" wurde für viele (viele != alle) Anwendungen irrelevant ist, weil das schlichtweg nicht der Bereich ist, in dem sie für den Anwender spürbar ausgebremst werden.

[luisk]

Zitat:

Zitat von Daniel (Beitrag 1310411)

Zitat:

Zitat von luisk (Beitrag 1310410)

Wenn C# inzwischen genauso schnell oder schneller als Delphi ist ?

Die überwiegende Menge an Performance-Problemen, die ich bei Kunden-Projekten bisher finden konnte, war nicht auf die Sprache bzw. deren Compiler zurück zu führen. Ich denke, dass das, was hier "gemessen" wurde für viele (viele != alle) Anwendungen irrelevant ist, weil das schlichtweg nicht der Bereich ist, in dem sie für den Anwender spürbar ausgebremst werden.

Die Frage ist, was spricht noch für Delphi im Vergleich zu C# ?

[MichaelT]

Der Faktor 10 ... Nein. Tut mir leid ;). Deckt sich nicht mit der Erfahrung. Möglw. hast du den Code ob der Größe zufällig in einem Cache im Prozessor. Du kannst wenn du willst den generierten Code vergleich was vermutlich bei einem Vergleich mit .net schwer wird. Delphi 64bit ist sicher nicht langsam und Delphi 32bit eigentlich auch nicht.

Einzig wirklich langsam ist der Extended Datatype in 32bit. Es gibt JVMs die können noch Erfahrung zur Laufzeit mitberücksichten. .net hat das soviel ich weiß nicht. Es haben sich aber auch die Hoffnungen nicht erfüllt mit einer Kombination aus JIT und Vorhersagen einen gewaltigen Speedup zu holen. Das ist allein bei Riesensystemen sinnvoll, wobei weder Java noch .net Assemblies zur Laufzeit können (im Sinne eines Modules in einem Server). JVM kommt schon hin in diese Richtung - das wurde auf der Uni Linz im Oracle Lab entwickelt.

Der mkinzler hat einen recht netten Test gemacht. JVM auf Linux ist so schnell wie .net unter Windows... Allein JVM unter Windows lässt ein wenig aus. Wenn man managed vs. unmanaged vergleicht im Benchmark dann darf man am Ende den Speicher nicht freigeben. Da ging es hart zur Sache mit Vergleichen und Objekte anlegen usw...

Du holst ungemanaged ca. eine Verdopplung raus. Das war eher zu Zeit der Dual Cores.

Der ABAP Prozessor ist bezüglich Floating Point ganz gut drauf, da können sie C# und Java ein Scheibchen abschneiden. Bei Java hängt die Sache wieder auf der JVM die verwendet wird. Alles andere und Floating Point kann man was Scripting angeht vergessen sofern nicht eine Funktion im puren C implementiert wird. GCC unter Linux ist etwas schneller als der MSC++ auf Windows ... Das ist kaum mehr vergleichbar.

Das Java ist ja im Businessbereich einfach beliebt, das es so restriktiv ist und teils sehr expressiv - Beispiel ... der 'Zwang' eine Exception zu handeln usw...

Gemanaged war damals (ist schon ein Weilchen) her halb so schnell. Du holst mit handoptimierten Code je nach Anwendung mit MS C/C++ fast das Optimum, selbst der Einsatz von einem Intel Compiler bringt grad mal 40 Speedup. Ein Freund von mir hat sich mal die Mühe gemacht und das war damals notwendig für eine Optimierung sich in Managed C++ multidimensionale Collections zu bauen. Der Grund warum er C++ brauchte war, da er die Antwortzeit unter den Bereich des Merkbaren wollte absenken. 2 Sekunden pro Planungslauf vs. 0.8 sec. Aber der Unterschied zur Optimierung die beim Kunden zuvor Nächte lief war, das Eliminieren von vermeintlichen Einflussfaktoren. Dann hat man 4 Stunden (Simulationssystem) vs. 20 Sekunden im ersten Schritt (C#), Optimierung von C# Code und Neustrukturierung (2-3 Sekunden) und am Ende eben den Umbau des Datencashes auf managed C++. Mit der Kürze der der Laufzeiten ändert sich die Architektur.

Erinnert so an ein anderen Bekannten der mal einfach ein File Diff gemacht hat und von 60k Zeilen bei Planungsläufen blieben pro Änderung so ca. 20 bis 200 Zeilen übrig und die wurden ins Data-Warehouse eingebucht.

Ich habe mich mal gespielt mit dem Heap. Eine 8GB Maschine unter Win32 und ein Baum mit 9 mit 9stelliger Knotenanzahl. (Mit dem Patch für Win7/32) damit man 4GB Adressraum schafft und die Maschine den gesamten Speicher kann nutzen, der war auf 8GB begrenzt. Einfach Operationen auf eine balancierten AVL Baum ... :-D. Viel Unterschied ist nicht.

Delphi Floating Point 64bit ist relativ schnell in Kombination mit Schleifen. Memory je nachdem. Das spielt dann alles zusammen. Delphi ist bestimmt nicht langsam. Es kommt halt dann draufan wie man sich den Speicher vom Windows holen lässt ...

Was ist der Grund. Schleifen sind Quantoren und damit lassen sie sich im Regelfall auf geschlossene Formen (Formeln) transformieren. (Paule, Schorns Implementierung des Gosper Algorithmus).
http://www.risc.jku.at/research/comb.../fastZeil.html

Zitat:

Zitat von luisk (Beitrag 1310308)

[/CODE]

Ergebnis: Delphi ist 10 mal schneller als C#
Kann jemand Angaben zu C++ machen ?

[Mavarik]

Zitat:

Zitat von luisk (Beitrag 1310412)

Die Frage ist, was spricht noch für Delphi im Vergleich zu C# ?

34 Jahr Erfahrung mit Pascal/Delphi.
Ein Sourcecode für iOS, Android, Mac, Windows.
Millionen Zeilen Sourcecode der seit Jahrzehnten problemlos funktioniert.
Jegliche innerbetriebliche Software und alle aktiven Projekt in Delphi erstellt...

Die Frage ist... Was hat je für C# gesprochen? Das ständig wechselnde Framework? :stupid:

[nuclearping]

Zitat:

Zitat von luisk (Beitrag 1310410)

Programmiert überhaupt noch jemand Delphi,
oder sind alle zu Microsoft gewechselt ?

Wenn C# inzwischen genauso schnell oder schneller als Delphi ist ?

Deine Frage liest sich wie: Isst hier überhaupt noch jemand Pflaumen, wenn man aus Birnen keinen Apfelmus machen kann?

Andernfalls kann ich mich den Aussagen der meisten hier nur anschliessen: Dein "Vergleich" hat keinerlei Bezug zur Realität oder Praxis. Ich habe Entwickler kennengelernt, die mit Delphi lückenlose Aufzeichnungen und Messungen im Gigabyte- und Nanosekundenbereich durchführen (müssen).

Und in unseren Projekten streamen wir Hardwaredaten über USB, um Messungen und Analysen für >100.000-1.000.000 Proben im Sekundenbereich durchzuführen. Und die Geschwindigkeit des durch den Delphi-Compiler erzeugten Codes war bis dato noch nie ein Problem.

Wer X Millionen Mal einen Button aktualisiert und dann daraus Schlussfolgerungen für das ganze Entwicklungssystem zieht, hat irgendwas nicht richtig verstanden.

Auch wenn die IDE von Embarcaderro nervig ist, ist die Programmiersprache Delphi nach wie vor immernoch mit eine der besten, performantesten und leserlichsten Sprachen auf dem Markt und mit eine der besten RAD-Lösungen.

[mensch72]

Delphi für Windows läuft & läuft.

Delphi(FMX) für CrossPlattform lebt vom Gedanken, das man sich als Entwickler eben möglichst nicht oder eben nur kaum um die System-GUI und die SystemStorage Gedanken machen soll.

C# für Crossplattform gibt es auch einige, nur da muss ich selbst im Design unten die StorageLogic absplitten, dann die "universelle" BusinessLogic portabel programmieren und darüber dann wieder eine Systemspezifische GUI setzen. Das Resultat ist sicher sehr effektiv und sehr nah an nativ, aber nicht das was ich "will". Bei FMX mit UniDac als StorageFramwork geht ~80% portabel, der Rest ist "basteln"... ich kann so damit leben.

Geschwindigkeit... nun ja wer einen "Mod" schnell will, der sollte es binär und in 2er Potenzen machen, also statt Mod 1000 eventuell besser genähert "&0x3ff" oder "and $3ff".

In "DelphiVCL" und "C++" kommt mann wenn es sein muss auch bit basiert noch sehr nah an Hardware heran. In C# oder DelphiFMX sollte man sich nicht primär mit "BitSchubsen" abgeben wollen.

"Geschwindigkeit","Optimieren"...
PC Programmierer sollten lieber "schönen" Code schreiben. Technik wird immer schneller und Speicherplatz kostet quasi nix.
Zufällig programmiere ich auch heute noch 8-Bit MicroControler mit 4KB-RAM und 64KB-Flash/ROM in C und vermeide ASM wo es geht. Der Programmstil ist dort automatisch etwas anders. (Viele Globale Variablen/Buffer zur Vermeidung wiederholter Übergabeparameter, statt for(...) lieber ein do{...}while(--xx) weil es einen 1:1 ASM Ersatz für while(--xx) gibt(DecrementJumpNotZero). Aber am PC mit Delphi oder was weiß ich ist mit sowas egal. Erst ab Giga- oder Terra-Bytes an Daten denke ich da an Speicher/Geschwindigkeit... bis Mega(bytes) ist das heute völlig wurscht.

[redox]

Ohne (wirklich) interessiert mitgelesen/verstanden zu haben:

Weshalb soll Delphi 6 (letztes Jahrtausend) eigentlich mit C# Express 2015 oder C++ (welche Version eigentlich) verglichen werden?

Warum nicht ein aktuelles FPC mit einem aktuellen GnU-C-sonstwas vergleichen?

Und seit wann ist es heute denn nicht mehr kälter als draußen?

Sorry, will nur den Thread noch etwas mehr aufblähen :oops::wink:

[luisk]

So, und jetzt noch die ganz gro0e Überraschung,
hab das ursprüngliche Testprogramm jetzt mal mit C# 2008 Express
laufen lassen. Die Release startet dort ganz einfach über "Start ohne Debugging"
( warum die keinen Release-Button spendieren konnten ??? )
Da ist C#2008 nun in 5 Sec durch, und damit sogar 3 mal schneller als Delphi bzw. C# 2015
(und damit 30mal schneller als die eigene C# Debug-Version).
Ups - jetzt seh ich C# mit etwas anderen Augen ! sorry https://de.wikipedia.org/wiki/Anders_Hejlsberg

Code:

        private void button1_Click(object sender, EventArgs e)
        {
            int li = 0;
            int lj = 0;
            double lw = 0.0f;
            double lc = 0.0f;
            for (li = 0; li < 50000; li++)
            {
                for (lj = 0; lj < 1000000; lj++)
                {
                }
                if (li % 1000 == 0)
                {
                    button1.Text = li.ToString();
                    button1.Update();
                }
            }

        }

von wegen, der Code taugt nicht zum Performance-Test

[Sir Rufo]

Ja, C# kann nutzlosen Bloat-Code viel besser wegoptimieren.

Schade, dass es bei mir so wenig davon gibt. Somit ist das für mich leider nicht das Killer-Feature.

[Bernhard Geyer]

Zitat:

Zitat von luisk (Beitrag 1310430)

von wegen, der Code taugt nicht zum Performance-Test

Wie schon gesagt: Wer Mist mist, mist Mist.

Hey, WinForms (ich denke mal du hast WinForms-Anwendungen genommen und nicht die auch unter 2015 verfügbaren anderen GUI-Ansätze) aktualsiert sich in einem blödsinnigen unter älteren C#/.NET-Versionen schneller - Mehr hast du nicht gemessen und mehr geben deine Messungen auch nicht her.

[luisk]

Hier noch das Consolenprogramm von mkinzler
das ist unter C# 2008 in 4,134 sec durch !:idea:
Von wegen, der Code eignet sich nicht zum Performancevergleich !
C# ich staune, dachte immer, die VM wäre lahm.
Das mit dem Debuggen läuft halt nicht so flott wie bei Delphi.
Von 10 mal so langsam zu 3 mal so schnell bei c#2008, ist doch ne super Erkenntnis !

Code:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace ConsoleApplication1
{
    class Program
    {
        static void Main(string[] args)
        {
            int li = 0;
            int lj = 0;
            int st = System.Environment.TickCount;

            for (li = 0; li < 50000; li++)
            {
                for (lj = 0; lj < 1000000; lj++)
                {
                }

            }
            int et = System.Environment.TickCount - st;
            Console.WriteLine(et);
            Console.ReadLine();
        }
    }
}

[Dalai]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1310433)

Wie schon gesagt: Wer Mist mist, mist Mist.

Durch Wiederholung wird die Schreibweise nicht richtiger. Korrekt (nach aktueller Rechtschreibung): Wer Mist misst, misst Mist. Nach alter Rechtschreibung würde man die ss mit ß ersetzen. SCNR

MfG Dalai

[Bernhard Geyer]

Zitat:

Zitat von Dalai (Beitrag 1310435)

Zitat:

Zitat von Bernhard Geyer (Beitrag 1310433)

Wie schon gesagt: Wer Mist mist, mist Mist.

Durch Wiederholung wird die Schreibweise nicht richtiger. Korrekt (nach aktueller Rechtschreibung): Wer Mist misst, misst Mist. Nach alter Rechtschreibung würde man die ss mit ß ersetzen. SCNR

MfG Dalai

Ändert aber nix an der Aussage

[Dalai]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1310436)

Ändert aber nix an der Aussage

Das hab ich ja auch nicht gesagt. Und ich stimme dir zu. Ich wollte nur die Schreibweise korrigiert wissen. Wir sind zwar nicht Google, die "first come first serve" mit "Wer zuerst kommt, malt zuerst" übersetzen, aber dennoch ;).

Sorry für OT.

MfG Dalai

[luisk]

Entscheidend bei den Messungen ist wohl das Kennen der Randbedingungen.
Für den eingangs gezeigten Code ist nun eines klar:

Delphi 6 : ca. 15 bis 16 sec. (Debug und Release) Super gut zu testen, da Debug so schnell wie Release.
C# 2015 : ca. 15 bis 16 sec. (Release) seltsam umständlich zu erstellen !
C# 2008 : ca. 4,2 sec. (Release) erstaunlich schnell !

C# 2015 : ca 199 sec im Debugmodus
C# 2008 : ca 118 sec im Debugmodus

damit kann man den gemessenen Mist schon mal etwas beurteilen.
Das tolle an Delphi ist, dass der Debugmodus im Prinzip genauso schnell ist, wie das Release.
Bei großen Datenmengen wird die Testerei bei C# wohl etwas langwierig.

Warum noch Delphi 6 ? Weils immer noch gut ist für Windows .... 32 Bit Anwendungen !

[creed steiger]

Zitat:

Zitat von luisk (Beitrag 1310439)

Warum noch Delphi 6 ? Weils immer noch gut ist !

Ergänzung:
Für den Anwendungsfall OS:Windows .... 32 Bit Anwendung erstellen

[mkinzler]

Fahradfahren ist auf einem Gehweg schneller als Stehen. Deshalb ist das Fahrrad auch das am Besten geeignete Fahrzeug für eine Reise zum Mars.

[Medium]

Abgesehen davon, dass dein Test auch nach Aquirierung von mehr Ergebnissen noch genau so aussagenbefreit ist wie zu Anfang, hier ein paar Gründe, warum Leute mit Sprachen programmieren, für die fragwürdige "Benchmarks" eher negativ ausfallen:

Für den gewerblichen Entwickler stellt sich die Frage nach roher Performance fast nie. Den weitaus größeren Optimierungsanteil findet man da eher auf ein paar Ebenen darüber, wie die verwendeten Algorithmen, das Design im Allgemeinen usw.
Der gewerbliche Entwickler muss auch gewaltig auf seine Produktivität achten. Wenn er gut in einer Sprache bzw. einem Framework geschulte Leute hat, kann ein Wechsel um ein paar Sekunden Laufzeit zu verkürzen gleich auch mal das nächste Release um Monate verschieben. Bis da hin ist die Firma in vielen Fällen platt, oder zumindest hinter der Konkurrenz. Hier ist auch extrem relevant, dass fast jedes Unternehmen auf millionen von Zeilen Legacy-Code sitzt, und nicht jeder Betrieb ist derart gut betucht, dass er mal eben einen kompletten Rewrite seiner gesamten Code-Basis stemmen kann. (Selbst wenn die Produkte an sich eigenständige Einheiten sind, die ohne Vorgängerversion waren, verliert man dennoch einen Haufen an Codefetzen, die man immer wieder mal einsetzt und Wochen einsparen können.)
Dort spielt auch die "Support-Infrastruktur" mit herein. Wenn ich für Delphi die Docs im Schlaf bedienen kann, meine Stammforen als Nachschlagewerke habe, weiss wo ich Komponenten und Codefetzen schnell beziehen kann, dann sind das alles Dinge, die ich mir über Jahre zusammengesucht und erprobt habe. Wechsle ich nun auf eine andere Sprache, hänge ich erstmal mächtig in der Luft. Das habe ich am eigenen Leibe erfahren, als ich für meine Bachelorarbeit interessehalbar erstmals C#, und auch gleichzeitig das erste Mal DirectX in die Hand genommen habe. Bis ich den ersten Code hatte, der ansatzweise das Erwartete gemacht hat, ist richtig Zeit vertrichen. Wohl dem, der früh genug anfängt. In der freien Wirtschaft hat man solche Leerläufe nicht.

Die Denke: "Ist langsamer, ich muss das andere nehmen" ist ausgeprochen kurzsichtig und, mit verlaub, kindisch und naiv. (Ich würde sogar ähnliche Adjektive für deinen konkreten "Test" hier ansetzen.)

Das zusammen mit der Tatsache, dass du seit 8 Seiten es nicht gebacken bekommst uns mitzuteilen welchem Zweck dein "Test" nachher dienen soll, lässt nur einen Schluss zu: Du vergeudest deine (und unsere) Zeit mit komplett irrelevanten Dingen, deren größerer Echtweltbezug mindestens höchst fragwürdig ist.

[jaenicke]

Auch wenn es schon ein paarmal geschrieben wurde...

Zitat:

Zitat von luisk (Beitrag 1310434)

Von 10 mal so langsam zu 3 mal so schnell bei c#2008, ist doch ne super Erkenntnis !

Dein Vergleich ist als ob du zwei Autowerkstätten vergleichst.

Du bringst in beide Werkstätten ein Auto mit Anhänger zum Tuning, weil du damit schnell eine größere Strecke zurücklegen möchtest.
Die eine Werkstatt schraubt jetzt den Anhänger ab, weil du ihn auf der Strecke gar nicht brauchst, die andere lässt ihn dran.

Und du vergleichst dann welches Auto schneller ist. Logisch, dass das Auto schneller ist, an dem der nutzlose Anhänger abmontiert wurde, oder?

Und genauso ist es bei deinem Code. Du packst eine leere Schleife hin, der eine Compiler merkt, dass sie nutzlos ist, und entfernt sie, der andere setzt deinen Code 1:1 um.
(Leere Schleifen kann man schließlich auch selber entfernen...)

Und jetzt vergleichst du welcher Code schneller ausgeführt wird. Logisch, der, bei dem die Schleife gar nicht mehr da ist zur Laufzeit.

Wenn du so etwas zumindest etwas realistischer vergleichen willst, musst du erstens in die Schleife auch etwas hineinpacken und darfst keine externen GUI Aufrufe oder ähnliches einbauen, weil die unberechenbare Auswirkungen haben und nichts mit der Umsetzung des Codes des Compilers zu tun haben.

[Daniel]

Moin,


dieses Thema bereitet mir Kopfschmerzen, weil der Themen-Ersteller gegen eine Wand läuft und aktuell nicht erkennst, dass da etwas im Weg ist. Selten waren sich die Foren-Teilnehmet so einig, dass dieser Weg der Vergleichsmessung nicht zum Ziel einer generellen Aussage führen kann. Die Gründe dafür wurden mehrfach genannt.

Performance-Messungen sind - so sie aussagekräftig sein sollen - mit erheblichem Aufwand verbunden, allein um eine Vergleichsfähigkeit der beteiligten Parteien wenigstens halbwegs herzustellen. "Kompilieren & Gucken was passiert" geht nicht einmal im Ansatz in Richtung dieses Ziels (insbesondere, wenn man sich in den Debug- und Release-Konfigurationen verheddert).


Ich mache hier mal zu.