Hallo
DP'ler,
das erste mal, daß ich eine Frage einstelle. Leider muß ich etwas ausholen:
Bin am basteln, wie ich unsere zwei teuren Brüder FireDac/UniDac toppen kann. Ich bin mit dem jetzigen Stand von Zeos-7.2 eigentlich ziemlich zufrieden. DevArt brauch ich nicht mehr nachzufragen, da as zu weit hinten liegt. FireDac ist jedoch in gewissen Bereichen noch interessant. Ich habe alle Treiber, sagen wir mal, nach Wunschliste, abgearbeitet. Zeos hat eigene Benchmark-Tests, um Performance-Vergleiche auszuführen. Der Sprung von <7.2 zu 7.2up ist gewaltig, je nach Anforderungen der Tests habe ich einen Performance-Zuwachs von Faktor 4 bis 20. Aber darum geht's jetzt nicht.
Am Ende steht da noch das Zeos-Protokol "
ADO" im Raum.
Derzeit benutze ich am liebsten die Tests von
http://synopse.info/fossil/wiki/Synopse+OpenSource, da diese externe Tests sind und nicht den Anschein erregen würden, sie wären in irgend einer Weise manipuliert.
Diese Test laufen ohne TDataSet oder der gleichen, direkter Zugriff auf's AdoRecordSet bzw. AdoCommand. Die Synopse Tests sind simpel und benchmarken 5000 Inserts und Lesen diese wieder. Wer's wissen will: sie basieren auf reiner UTF8-codierung, Ist aber hier im Kontext nicht notwendig, da ja nach nicht
ADO-Treiber die Performance x10-20 dagegen steht.
Das brachte mich zum Grübeln. Entweder ist
MSSQL einfach nur 'ne Schnecke oder de Hammer hängt ganz wo anders! Also begann ich im Zeos-Projekt zu suchen und zu basteln.. Ohne wirkliche Erfolge, wenn
ADO zum Tragen kam.
Vor drei Wochen schenkte mir mein Vater mal wieder eines seiner alten Bücher:
ADO-Programmierung von MS Press, Autor ist David Sceppa. Habe mir die 300 Zeiten mal schnell komplett gegönnt, um etwas zu lernen. Erfahren wollte ich freilich, wie man
ADO "tunen" kann und was der beste Weg für BATCH Executions wäre:
ADO unterstützt das nur via AdoRecordSet -> implementiert -> hust, prust. Da kann ich's auch manuell Row By Row machen! -> Implementiert -> 20% schneller als übers AdoRecordSet.
Erstes Zahlen zum Vergleich & Merken von den Synopse-Test (inserts/Sekunde VOM LESEN WILL ICH WIRKLICH NOCH GAR NICHT REDEN!):
Zitat von
Zeos-7.2 DBC ADO-direct:
{
"Engine": "ZEOS
MSSQL ADO",
"CreateTableTime": "3.73s",
"NumberOfElements": 5000,
"InsertTime": "4.42s",
"InsertRate": 1129,
"InsertBatchTime": "975.32ms",
"InsertBatchRate": 5126,
"InsertTransactionTime": "3.59s",
"InsertTransactionRate": 1391,
"InsertBatchTransactionTime": "529.30ms",
"InsertBatchTransactionRate": 9446
}
Also das war ja so ernüchternt! Eigentlich habe ich mich regelrecht vera....t gefühlt. Das kann's ja wohl echt nicht sein. Bezahlst einen Batzen Kohle für
MSSQL und dann das:
MSSQL + MS
ADO!!! Abgesehen vom Feature-Verlust im Vgl. zu
FB.
Somit begann ich zu überlegen, wo denn dieser unglaubliche DROP her kommt:
Verschieden Versionen von SLQLNCLI .... nö keine merklichen Unterschiede.
Dann folgte nur die Logik.
ADO ist nicht's weiter als ein End-User freundlicher Wrapper für OleDB. Alles in schöne Interfaces verpackt, Locale Typen kein Problem usw.. Was wäre, wenn ich via AdoCommand direkt mit OleDB kommunizieren könnte? Umgehe mal den ganzen OleVarinat Quark, und liefere, was der eigentlich Treiber will?
Erster versuch, klappt. Jedoch haben wir Tests, welche mich Zwangen alles nochmal umzuwerfen -> never discuss with the users!
Zweiter Versuch,
ADO im Vordergrund, via QueryInterface das AdoCommand umgangen und nur noch mit ICommand/ICommandText/ICommandPrepare/IAccessor all meine Wünsche ausgeführt: ist 5-10%langsamer als VS1 mit OleDB. Resultate(FÜR JEDEN SELBER MESSBAR):
Zitat von
Zeos-7.3 OleDB direct from and bypassed ADO:
{
"Engine": "ZEOS
MSSQL ADO+OLEDB",
"CreateTableTime": "253.06ms",
"NumberOfElements": 5000,
"InsertTime": "880.99ms",
"InsertRate": 5675,
"InsertBatchTime": "619.58ms",
"InsertBatchRate": 8069,
"InsertTransactionTime": "455.54ms",
"InsertTransactionRate": 10975,
"InsertBatchTransactionTime": "150.37ms",
"InsertBatchTransactionRate": 36251,
}
Hossa! Da sieht doch die Welt gleich ganz anders aus! Immer noch nicht perfekt/vergleichbar mit anderen Providern, doch ein merklicher Zuwachs der Performace!
Wem die Test's nicht gefallen: Schaut mal im 7.3er
SVN von Zeos, wie man das
ADO gequarke umgeht, implementiert es & vegleicht selber.
ES rockt mit direkt OleDB und hinkt mit
ADO.
Nun die eigentliche Frage, wenn mann bedenkt, daß Zeos nur über Defaults das Treibers zugreift, das Handbuch darauf vereist, daß
ADO in JEDEM Falle die best mögliche Einstellungen ja nach Provider trifft...
Wer kennt sich mit
ADO aus?
Was geht da noch? Übersehe ich Settings, die ich nicht kenne und ich im MS-Buch nicht zu finden vermag?
Wo und wie muß ich die Knöpfe drücken, um ein bischen zu Lächeln? Wäre über jeden "sinnvollen" Gedanken erfreut.
Im Buch beschrieben steht nich viel: "Über meine gesamte Zeit, habe ich noch nie veränderte Properties gesehen"... "mit
ADO lassen sich High-Performance erstellen"....BlaBla Alles vom MS Autor.
Was kann man tun, um wenigstens im Ansatz aus 'nem "Veralteten, lahmenden Esel" einen "galloppierendes Pferd" zu machen? ICE erwartet ja keiner, wenn mann bedenkt, das
ADO eigenen Speicher reserviert & OleDB auch noch dazu und DANN erst kommst du!
Michael
Ps. Direkt OleDB-Wrapper ist fast fertig für 7.3. Dennoch ist die Frage zwar nostalgisch aber ernst gemeint! Was geht denn da noch?
mein Connect String:
Zitat von
ADO ConnectionString:
Provider=SQLOLEDB.1;Persist Security Info=False;Initial Catalog=zeoslib;Trusted_Connection=Yes;Data Source=EGONDEVLAPTOPW7\SQLEXPRESS;Use Procedure for Prepare=1;Auto Translate=True;Packet Size=4096;Workstation ID=EGONDEVLAPTOPW7;Use Encryption for Data=False;Tag with column collation when possible=False