Ich glaube du verfehlst denn Sinn eines RDBMS
Im Bench Beispiel hier definitiv, aber da die Anzeige der Daten (und durchaus auch großer Datenmengen bzw. aller Daten) nunmal ein Hauptbestandteil des realen Programms ist darf ich das natürlich bei der Frage ob sich ein Umstieg auf SQL lohnt oder auch nicht lohnt natürlich nicht vernachlässigen.
Der Geschwindigkeitsvorteil kommt, sobald du Bedingungen hast.
Willst du immer alle Datensätze aus der Datenbank abrufen? Wohl eher nicht
Eine einzige WHERE Bedingung sollte den Geschwindigkeitsvorteil eigentlich schon deutlich machen.
Natürlich nicht immer, aber z.B. zum Programmstart und auch immer dann wenn die Filter des Listviews zurückgesetzt werden. Manche Filter schränken auch kaum ein, daher entstehen selbst bei Filterung teilweise noch über 1000 Ergebniszeilen. Daher ist die Performance insbesondere in diesem Fall sehr wichtig. Klar wenn der Filter wirklich stark einschränkt oder nur das Ergebnis einer Berechnung (sum/avg...) relevant ist dürfte SQL deutlich im Vorteil sein, das habe ich oben aber denke ich auch schon erwähnt.
Da mir der Vorteil also durchaus bewusst ist war eben die Frage ob ich noch Möglichkeiten habe den eher ungünstigen Fall, also viele Ergebniszeilen irgendwie zu beschleunigen. Mit 600ms kann ich im Moment leben, das Problem ist nur, dass die Daten in 1-2 Jahren den doppelten Umfang haben werden und wir dann nicht mehr von 600ms, sondern von 1,2 Sekunden reden, was eher unschön wäre und den Einsatz einer SQL Lösung aus Performance sicht in Frage stellt.
Oder auch, sollte sich deine Datenbank weiterentwickeln, mehrere Tabellen (3te. Normalform etc), JOINS,
VIEWS wie du schon gesagt hast, Hinzufügen, ändern und Löschen von einzelnen Datensätzen oder auch größeren Datenmengen,
darin liegt der Vorteil eines RDBMS
Jupp, das war naürlich alles angedacht, allerdings bin ich mir noch nicht sicher ob es wirklich sinnvoll wäre eine Normalisierung vorzunehmen. Ich spare dadurch zwar Redundanz ein, allerdings gestaltet sich die Verwaltung komplexer und die Zugriffsgeschwindigkeit leidet vermutlich auch ein wenig (zumindestens hat das meine Lehrerin mal behauptet). Da ich das Thema aber prinzipiell interessant finde werde ich das auf jedenfall irgendwann mal in Angriff nehmen. Schon alleine weil ich all mein theoretisches Wissen in diesem Bereich bislang kaum praktisch anwenden konnte/musste.
Selbes Ergebnis, aber 10mal SchnellerPRAGMA TABLE INFO: 3.01685434320743
_SQLite_FetchNames: 0.352390055538509
Verdammt die Funktion ist mir ganz entgangen. Hätte ich mir die Recherche auf der sqlite page sparen können. 
Letzlich aber eh nur ein Gewinn von 3ms, also nicht wirklich der Rede wert, das Listview wird ja glücklicherweise nicht tausende male neu erstellt.
So nun zurück zum eigentlichen Problem:
Ich habe nachwievor den Verdacht, dass die 3000 Aufrufe von FetchData (dürften jeweils Autoit DLL calls sein) den Flaschenhals darstellen und nicht die Zeit die Sqlite für die Erstellung der Ergebnistabelle oder das Parsing des SQL Befehls verschlingt. Daher hatte ich noch einen Gedanken wie man prinzipiell die Zeit massivst verkürzen könnte. Theoretisch könnte ich wie folgt vorgehen:
1. Stored function in der DB erstellen, welche das SQL Query erledigt und sämtliche Ergebniszeilen verkettet und in einer einzigen Rückgabvariable speichert.
2. Stored function in Autoit aufrufen, es sollte nun nur noch ein einziges FetchData nötig sein um einen riesigen String, der die ganze Tabelle enthält zu bekommen
3. String per Autoit wieder in Zeilen zerlegen und damit das Listview befüllen
Praktisch scheitert das Vorhaben aber offensichtlich daran, dass SQLite keine stored functions/procedures kennt. Und ja das Vorhaben klingt auch äusserst eklig, dennoch hätte so theoretisch die Zahl der "externen" DB Zugriffe / dll calls deutlich reduziert werden können.
Nun gut es scheint eh nicht zu gehen, also erstmal wieder verworfen.
Könnte man eine Zeilenverkettung auch mit einem verschachtelten Select hinbekommen? Die Frage wäre aber auch ob der Zeitgewinn durch die Reduzierung der dll calls letztlich nicht wieder durch das Stringsplit in Autoit aufgefressen wird...
'|' 
