Zum Thema "schneller":
Hab gerade mal ein Testproggy geschrieben, in dem mit allen Datentypen eine simple Addition+Zuweisung abläuft, in einem Thread mit Priorität = tpTimeCritical; Messmethode = GetTickCount; Berechnungen pro Typ = 2.000.000.000
var3 := var1 + var2;
wobei var1 = 1 und var2 = 2
Code:
ShortInt: 3125 ms
SmallInt: 3157 ms
LongInt : 2422 ms
Integer : 3125 ms
Byte : 3125 ms
Word : 3125 ms
LongWord: 3188 ms
DWord : 3125 ms
Cardinal: 2437 ms
Int64 : 4375 ms
Single : 3359 ms
Real48 : 100016 ms
Double : 5109 ms
Comp : 5282 ms
Currency: 5328 ms
Extended: 15625 ms
=> Ob nun Byte oder Integer ist sch****egal, da eh auf aktuellen CPUs mit 32 Bit gerechnet wird!
Interessant finde ich hingegen, dass ein LongInt doch deutlich schneller ist als ein Integer, obwohl sie laut in D7 identisch sein
LongWord und DWord haben ein ähnliches Verhältnis zueinander, und brauchen auch fast gleich lange.
Ganz hervorragend find ich ja Real48
, und dass Extended
so langsam im Vergleich zu Double ist, hätte ich nicht gedacht. Int64 dagegen ist ja sogar recht fix: Tatsächlich nur eine Verdopplung des Aufwandes, wie man es vermuten würde. Single->Double dagegen nicht mehr verdoppelt, aber das mag daran liegen, dass die FPU eh auf 64 Bit angelegt ist, und Double keine Verdopplung der in der Architektur vorgesehenen Bitzahl darstellt, sondern im Gegenteil Single eine Halbierung. Der Aufwand hätte
imho sogar gleich sein müssen, aber so wie ich die IA-32 Specs verstanden habe hat die FPU für Single-Werte einen eigenen Modus. Daher wohl kein 1:2-Verhältnis.
Tja, viel gelabert, und gleich noch eine Tabelle mit (fast) allen einfachen Datentypen geliefert... (Real fehlt; habbich vergessen. Sollte mit Double gleich sein, aber das ist ja scheinbar nicht zwangsläufig so (vgl. LongInt->Integer)).
gruss,
dizzy
\\edit:
Mit diesem Post bin ich in den erlauchten Kreis der Excellent-Member aufgestiegen. Die stellen hier ja die kleinste Gruppe dar
*froi*
Fabian K.
INSERT INTO HandVonFreundin SELECT * FROM Himmel