Was ich jetzt noch festgestellt habe: die Wahl der "richtigen" Transaktionsgrösse ist ganz entscheidend für die Geschwindigkeit, und mein erster Ansatz (500 Zeilen pro Transaktion einlesen" war ziemlich weit daneben. Wenn ich statt nach 500 Zeilen erst nach 15000 Zeilen (ca 36000 Inserts) ein Commit mit anschliessendem neuen Transaktionsstart mache, braucht das Programm weniger als die Hälfte der Zeit, nämlich 2:51 in Verbindung mit prepared Statements statt knapp 6 Minuten. Ein weiteres Vergrössern der Transaktion verlangsamt allerdings das Programm wieder. Die optimale Transaktionsgrösse wird vermutlich von einer Menge Faktoren abhängen und nicht leicht zu bestimmen sein, sie ist aber jedenfalls sehr viel grösser, als ich gedacht hatte.
@mkinzler
Das Ergebnis des Tests legt nahe, dass Firebird keinen Statement-Cache verwaltet, um sich das wiederholte Ausführen von prepare zu sparen. In meiner Einleseschleife gibt es 4
SQL Statements, die der Reihe nach aufgerufen werden. Würde Firebird mit einem Statement Cache arbeiten, dann müsste die Variante mit execute immediate mit Parametern annähernd so schnell sein wie die mit manuellem Prepare, die 4 Statements wären ja dann nach der ersten importierten Zeile schon vorbereitet im Cache. Tatsächlich ist diese Variante aber ebenso langsam wie die Variante execute immediate ohne Parameter, bei der jedes Statement anders aussieht und ein Cache deshalb keinen Vorteil bringen würde.
Zitat
Baum-Darstellung
