Vergleich Firebird: C# vs. Delphi Win32

[Satty67]

Zitat von Phoenix:

im worst case noch mit attachtem debugger laufen lässt wird das dann *richtig* langsam.

...oder anders ausgedrückt Zeitmessung mit Strg-F5 (statt F5)

Morphies Beispiel-Code ist bei mir ohne Debugger ziemlich genau um den Faktor 8 schneller.

(ohne string + string + string und DoEvents bei jedem Durchlauf sollte es vergleichbar schnell wie mit Delphi sein)

[Phoenix]

Zitat von Satty67:

Morphies Beispiel-Code ist bei mir ohne Debugger ziemlich genau um den Faktor 8 schneller.

(ohne string + string + string und DoEvents bei jedem Durchlauf sollte es vergleichbar schnell wie mit Delphi sein)

Naja, das

Code:

label2.Text = i.ToString() + " / " + max.ToString();

ist eine einzige Konkatenation und erzeugt lediglich eine neue String-Variable. Das sollte verschmerzbar sein und nicht stören. Am besten packt er das ganze in einen Background-Thread (wurde schon angesprochen), die Label - Aktualisierung dann in eine jeweils neue anonyme Methode und schmeisst die dann zum Invoken auf den Mainthread. So hat die DB-Geschichte einen kompletten Kern für sich und das UI darf versuchen hinter den ganzen Aktualisierungen herzulaufen

[Morphie]

wie gesagt, das war nur eine Testanwendung Die eigentliche Anwendung ist natürlich sauberer...
Zu euren Vorschlägen:
Mit Strg + F5 läuft das ganze schon wesentlich schneller! Das war anscheinend das Kernproblem...

Jetzt bin ich mit 10000 Datensätze bei ziemlich genau 4 Sekunden. Ich denke das reicht soweit.
Delphi braucht bei entsprechendem Code nun ca. 2,2 Sekunden.

Vielen Dank

[Phoenix]

Zitat von Morphie:

Zu euren Vorschlägen:
Mit Strg + F5 läuft das ganze schon wesentlich schneller! Das war anscheinend das Kernproblem...

Ja, der Debugger analysiert ne Menge mit im Hintergrund. Performancetests daher immer ohne Debugger machen. Und die 2 Sekunden Differenz bekommst Du auch noch raus

[Morphie]

Hast du da zufällig einen Tipp wie ich das machen könnte?
Klar, irgendwann wird das in einen Thread ausgelagert, aber von der Ausführungszeit sollte das doch noch keinen Unterschied machen...

Die Schleife sieht nun so aus:

Code:

const int max = 10000; // < Anzahl
for (int i = 0; i < max; i++)
{
    // Werte den Parametern zuweisen
    Cmd.Parameters["Par1"].Value = i;
    Cmd.Parameters["Par2"].Value = i;
    Cmd.Parameters["Par3"].Value = "Test";
    Cmd.Parameters["Par4"].Value = DateTime.Now;

    // Command durchführen
    Cmd.ExecuteNonQuery();

    // Nach jeweils 3000 Datensätz die Transaktion "committen"
    if ((i % 3000) == 0) Trans.CommitRetaining();
}

wüsste nicht, was ich da noch optimieren könnte...

[Phoenix]

Zitat von Morphie:

wüsste nicht, was ich da noch optimieren könnte...

Ich schon
Der Indexer-Zugriff auf den Parameter muss nicht innerhalb der Schleife passieren, weil das jedesmal ein Loopup ist. Das reicht wenn man den ein einziges mal macht, und nicht 40.000 mal

Code:

var param1 = Cmd.Parameters["Par1"];
var param2 = Cmd.Parameters["Par2"];
var param3 = Cmd.Parameters["Par3"];
var param4 = Cmd.Parameters["Par4"];

const int max = 10000; // < Anzahl
for (int i = 0; i < max; i++)
{
    // Werte den Parametern zuweisen
    param1.Value = i;
    param2.Value = i;
    param3.Value = "Test";
    param4.Value = DateTime.Now;

    // Command durchführen
    Cmd.ExecuteNonQuery();

    // Nach jeweils 3000 Datensätz die Transaktion "committen"
    if ((i % 3000) == 0) Trans.CommitRetaining();
}

Alternativ kannst Du Dir die Referenzen auf die Parameter auch gleich beim Erzeugen der Parameter merken, dann sparst Du Dir die 4 Lookups zu Beginn auch nochmal, da wär allerdings wirklich mikrooptimierung.

[tsteinmaurer]

@Morphie: Wird nicht mehr so viel bringen, aber anstatt CommitRetaining ein normales Commit machen. Somit ist es aus Sicht von Firebird keine langlaufende Transaktion und die OIT/OAT kann nachziehen.