Moin,
das hängt von verschiedenen Faktoren ab, u.a. deinem Tabellendesign, aber auch generell davon, das du halt TTable Varianten benutzt. Da sind längst nicht alle Komponentenvarianten schnell und die treiben meistens einen Riesen Overhead gegenüber reinen
SQL Komponenten, bei denen du bestimmt, welches
SQL ausgeführt wird und wann es ausgeführt wird. Wenn du sehr viele Felder in deinen Tabellen hast müssen wesentlich mehr Metadaten geladen werden.
Was Firebird wirklich macht kannnst du z.B. bei FB25 mit der TraceAPI erkennen
http://ibexpert.net/ibe/index.php?n=Doc.TraceAndAudit (geht auch mit der IBExpert Trial, aber nicht mit der Personal, gibt aber auch andere Tools)
Dazu kommt dann noch die von dir benutzte Firebird Version. Wenn es der Superclassic oder classic ist und du anden Cache Buffers nichts geändert hast, dann liegt wohl auch da der Hund begraben. Beim Superserver, den ich für jeden empfehle, der sich weniger mit
FB auskennt, der default cache buffer mit 2048 ok, beim classic oder superclassic mit 75 viel zu gering. sehe kannst du den Wert in der Datenbankstatistik oder hier
http://ibexpert.net/ibe/index.php?n=...baseProperties (da kannst du den wert auch höher setzen, Mindestwert 2000, besser 10000).
Ich hab mir die statischen Datenmodule mit hunderten von Komponenten schon vor Jahren abgewöhnt. Bei diversen Delphi Consulting Jobs sehe ich aber noch Datenmodule mit hunderten von Datasets, das ist kaum wartbar, entsteht aber meistens im Laufe der Jahre weil man mal so angefangen hat und nun an zig tausend TField Objekten und TDataset Events was rangebastelt hat, was man nicht mal eben ändern kann. Ich erzeuge alle Datasets zur Laufzeit, aber performancemäßig macht das eigentlich keine Unterschied.
Wenn es geht, dann vermeide generell TTable Varianten, da geht Komfort für den Programmierer zu Lasten Performance für Endanwender.
Evtl. hast du aus der TraceAPI ode rdurch geänderte Cache Buffers ja schon neue Erkenntnisse