Firebird + ZEOS: Erste query langsam

[blackfin]

Hallo liebe Experten,

Mir kommt etwas in Firebird Embedded + ZEOS etwas komisch vor:
Die erste Query dauert immer extrem lange, nämlich bis zu 10x so lange wie eine darauffolgende Query.
Das merkwürdige daran ist, dass es egal ist, ob ich als erste Query von einem komplett anderen table Selektert habe als bei der zweiten Query,
dann ist die zweite Query trotzdem schneller.

Beispiel:

Code:

'SELECT * FROM foo'

=> Ausführungszeit: 11 ms

danach nochmal:

Code:

'SELECT * FROM foo'

=> Ausführungszeit: 1 ms

Das kann ich jetzt noch mit einem Firebird internen Cache erklären.
ABER das folgende nicht:

--Programm-Neustart--

Code:

'SELECT * FROM bar'

=> Ausführungszeit: 12ms

danach:

Code:

'SELECT * FROM foo'

=> Ausführungszeit: 1 ms


Das verwirrt mich. Ist das ein Bug in ZEOS? Hat jemand schon ähnliche Erfahrungen damit gemacht?

[mirage228]

Also bei 10ms würde ich ja fast schon von einer Messungenauigkeit des Timers sprechen... Womit hast Du gemessen?

[Bernhard Geyer]

Wenn nur 10 ms sind - gähn.
Hier werden wohl bei der ersten Query interne Caches etc. aufgebaut. Und solche Caches etc. sind nicht unbedingt Tabellenspezifisch.

[mkinzler]

Oder Zeos baut die Verbindung zum Server erst zu diesem Zeitpunkt auf

[blackfin]

Zitat:

Also bei 10ms würde ich ja fast schon von einer Messungenauigkeit des Timers sprechen... Womit hast Du gemessen?

Die Messroutine sieht folgendermaßen aus:

Delphi-Quellcode:

procedure CalibrateCPU() ;
var
 t,t2 : Int64 ;
begin
  t := GetTickCount;
  while t=GetTickCount do;
  t2 := GetCPUTicks;
  while GetTickCount<(t+400) do;
  t2 := GetCPUTicks - t2;
  CPUClock := 2.5e-6*t2;
end;

// CPU Cycles Count
function GetCPUTicks: Int64;
asm
   DB $0F,$31
end;

// Start Time Measurement
procedure StartGetTime() ;
begin
    ticks := GetCPUTicks() ;
end ;


// End Time Measurement
function EndGetTime(const InMilliSeconds: boolean = true) : OleVariant ;
var
  ticks2 : Int64 ;
begin
    ticks2 := GetCPUTicks() - ticks;
    if not InMilliSeconds then
      Result := ticks2 / CPUClock
    else
    Result := FloatToStrF((ticks2 / CPUClock) / 1000,fffixed,15,1) ;
end;

Beim Programmstart wird einmal CalibrateCPU() ausgeführt, und dann vor der Query ein StartGetTime() und direkt nach der Query ein EndGetTime(); ausgeführt.

Zitat:

Wenn nur 10 ms sind - gähn.

Hast eigentlich recht, aber das kann für mein Vorhaben u.U. doch relevant sein..naja egal :)

Zitat:

Oder Zeos baut die Verbindung zum Server erst zu diesem Zeitpunkt auf

Es gibt keinen "Server", ist ja embedded. Und das "connect" zur Datei passiert definitiv schon vorher.

[Stevie]

Deine Methode der Zeitmessung ist sowieso schrecklich ungenau. (Abweichungen von ~3%, hab einfach in ner Schleife nen Sleep(100) gemessen)
Warum nicht QueryPerformanceCounter?

[blackfin]

sleep() ist selbst ungenau und gearantiert nur, dass mindestens diese Zeit gewartet wird, kann aber auch etwas länger sein :)

Aber mal sehen, den Performance-Counter probiere ich auch mal aus!
Obwohl mir die Abweichung der Zeitmessung von ~3-4% eigentlich in diesem Fall egal ist, denn es geht bei meinem Problem um viel grössere Dimensionen als diese minimale Abweichung von ~3% bei der Query-Ausführung, nämlich um den Ausführungs-Faktor 10 oder mehr :)

Edit:
Der Thread kann als geschlossen betrachtet werden, ich werde erstmal selbst ein paar Dinge ausprobieren.

[Stevie]

Zitat:

Zitat von blackfin (Beitrag 1035077)

sleep() ist selbst ungenau und gearantiert nur, dass mindestens diese Zeit gewartet wird, kann aber auch etwas länger sein :)

Richtig, wenn das System nicht sofort Rechenzeit zur Verfügung stellt.
In meinem Test war das aber nicht ausschlaggebend. Mir gings nur um den Vergleich deiner Methode und TStopwatch (neu in Delphi 2010 in der Unit Diagnostics, ist aber nix anderes als nen angenehm zu nutzender Wrapper für QueryPerformanceCounter)