Kodieren gegen großes Datenvolumen (Datendatei > 2 GB, > 15 Mio. DS)

[jobo]

Also erstmal mein Kompliment zur Optimierung der Anwendung. Diese Mühen nimmt selten jemand auf sich. Der Anlaß trübt allerdings meine Begeisterung etwas. Ich hab zu dem Thema "3" Punkte:
- Bei Deinen Optimierungen sollte Dir klar sein, dass Deine Anwendung ggF. nicht die einzige auf dem PC ist. Datensatzzahlen bzw. Verarbeitungsgeschwindigkeit sind also vielleicht trügerisch.
- Zum empfohlenen Einsatz von Datenbanken und deinen Worten von der Verarbeitung von Milliarden Datensätzen: Der Einsatz einer DB Engine macht aus einem Desktop (oder Racksystem) keinen Quantencomputer. Das Prinzip beruht hauptsächlich auf der gezielten und kleinteiligen Verarbeitung eines Datenausschnitts. Also große "Festplatte", optimierter Zugriff, kleine OPs. Solltest du wirklich in die Verlegenheit kommen, Milliarden Daten zu >verarbeiten<, wirst Du schnell die Grenzen dieser Systeme kennenlernen.
- SQL als Standard ist leider schwierig. Sobald Du in der Anwendung Query Komponenten verwendest, kommt wahrscheinlich irgendwann der Punkt, wo Du proprietäre Syntax verwendest, besonders bei der "Verarbeitung von Milliarden DS". Performancebedarf wird in SQL häufig mit proprietären Lösungen gedeckt. Allein die Vielfalt der existierenden Systeme (Deins inkl.) und die Verschiedenheit der Ansätz (noSQL, ..) spiegeln den recht unterschiedlichen Bedarf und eben die Lösungswege.
- CSV kann heute fast jede DB Engine von sich aus einlesen.

Ich habe bei der Schilderung deiner Situation an ORM Systeme denken müssen. Damit kannst Du vielleicht eine ggute Trennschicht zwischen Dein (gewohntes) System und die DB ziehen. Außerdem musste ich an die Arbeit von @haentschman denken, mit ihm solltest du vielleicht mal ein Bier trinken gehen.

[TiGü]

Du könntest noch ein bisschen mit der neuen Möglichkeit spielen, deine eigene Wachstumsstrategie für Collection-Klassen zu implementieren.
Wenn dir im Vorfeld die maximale Größe der Datenstrukturen bekannt ist und du die vor dem Füllen setzen kannst, dann kannst du das neu allozieren und umkopieren des darunterliegenden Arrays im Grenzbereich sparen.
Ein paar Prozent mehr Speicheroptimierung und/oder Performance lässt sich vielleicht rausschinden.

http://blog.marcocantu.com/blog/2018...ments-rio.html
http://docwiki.embarcadero.com/Libra...CollectionFunc

[Harry Stahl]

Zitat von TiGü:

Du könntest noch ein bisschen mit der neuen Möglichkeit spielen, deine eigene Wachstumsstrategie für Collection-Klassen zu implementieren.
Wenn dir im Vorfeld die maximale Größe der Datenstrukturen bekannt ist und du die vor dem Füllen setzen kannst, dann kannst du das neu allozieren und umkopieren des darunterliegenden Arrays im Grenzbereich sparen.
Ein paar Prozent mehr Speicheroptimierung und/oder Performance lässt sich vielleicht rausschinden.

http://blog.marcocantu.com/blog/2018...ments-rio.html
http://docwiki.embarcadero.com/Libra...CollectionFunc

In Delphi 10.3 ist wohl "Dictonary.Tryadd" neu / optimiert worden, bringt noch 100-200 ms bei ca. 2 Mio DS (statt if not Dictionary.contains, then add).

Was ich festgestellt habe, was viel Zeit kostet, ist die Sortierung der Stringlisten, wenn nach Textinhalten sortiert werden soll. Insbesondere, wenn (was ja Standard ist) Stringlist.uselocale auf True ist. Bei deutschen Textinhalten (Umlaute!) braucht man das aber leider, kann man aber ausschalten, wenn nur auf ein Integer-Feld sortiert wird und keine 2 oder 3. Text-Sortierfeld verwendet wird.

Wenn .Uselocale aktiv ist, wird in "TStrings.Comparestrings" die Funktion "AnsiCompareText" (statt sonst "CompareText") verwendet, was recht langsam ist (12 Sekunden, statt 4 Sekunden mit CompareText).

Gibt es dazu keine bessere Lösung?

[Harry Stahl]

Zitat von jobo:

Also erstmal mein Kompliment zur Optimierung der Anwendung. Diese Mühen nimmt selten jemand auf sich. Der Anlaß trübt allerdings meine Begeisterung etwas. Ich hab zu dem Thema "3" Punkte:
- Bei Deinen Optimierungen sollte Dir klar sein, dass Deine Anwendung ggF. nicht die einzige auf dem PC ist. Datensatzzahlen bzw. Verarbeitungsgeschwindigkeit sind also vielleicht trügerisch.
- Zum empfohlenen Einsatz von Datenbanken und deinen Worten von der Verarbeitung von Milliarden Datensätzen: Der Einsatz einer DB Engine macht aus einem Desktop (oder Racksystem) keinen Quantencomputer. Das Prinzip beruht hauptsächlich auf der gezielten und kleinteiligen Verarbeitung eines Datenausschnitts. Also große "Festplatte", optimierter Zugriff, kleine OPs. Solltest du wirklich in die Verlegenheit kommen, Milliarden Daten zu >verarbeiten<, wirst Du schnell die Grenzen dieser Systeme kennenlernen.
- SQL als Standard ist leider schwierig. Sobald Du in der Anwendung Query Komponenten verwendest, kommt wahrscheinlich irgendwann der Punkt, wo Du proprietäre Syntax verwendest, besonders bei der "Verarbeitung von Milliarden DS". Performancebedarf wird in SQL häufig mit proprietären Lösungen gedeckt. Allein die Vielfalt der existierenden Systeme (Deins inkl.) und die Verschiedenheit der Ansätz (noSQL, ..) spiegeln den recht unterschiedlichen Bedarf und eben die Lösungswege.
- CSV kann heute fast jede DB Engine von sich aus einlesen.

Ich habe bei der Schilderung deiner Situation an ORM Systeme denken müssen. Damit kannst Du vielleicht eine ggute Trennschicht zwischen Dein (gewohntes) System und die DB ziehen. Außerdem musste ich an die Arbeit von @haentschman denken, mit ihm solltest du vielleicht mal ein Bier trinken gehen.

Ja, das mit den Mrd. Datensätzen war vielleicht auch ein wenig hoch gegriffen...

SQL finde ich sehr interessant, wie man mit recht einfachen Sprachkonstrukten Auswahlen von Daten bzw. neue Tabellen anlegen kann. Sehr schön, schon beschlossene Sache, dass ich in Version 5 die wesentlichen SQL-Befehle als Alternative zu meiner eigenen Lösung unterstützen werde.

[Blup]

Zitat von Harry Stahl:

Soweit habe ich das dann tatsächlich hinbekommen, dass ich in der 32-Bit-Version die 2,1 Mio. DS importieren und anzeigen lassen kann (schnell ist das Programm aber dann nicht mehr, in der allgemeinen Anzeige schon, aber in der Filterung von DS nicht, dazu später).

Es ist nicht sinnvoll so viele Datensätze im Arbeitsspeicher zu halten.
Es gibt bessere Konzepte z.B.:

Vorbereitung:
- temporäre Datenbank erzeugen
- Tabelle mit den Spalten der CSV-Datei anlegen
- CSV-Datei in die Tabelle einlesen
- jeweils einen Index auf Spalten setzen, die gefiltert oder sortiert werden können
Anzeige:
- je nach Filter/Sortierung die SQL-Anfrage anpassen
- die Anzahl der anzuzeigenden Datensätze ermitteln und Anzeige vorbereiten (z.B. TDrawGrid.RowCount)
- nur die Datenzeilen lesen, die tatsächlich gerade im Fenster sichtbar sind (z.B. Zeile 1- 150) (Daten für die Anzeige bereitstellen z.B. TDrawGrid.OnGetEditText)
- beim Scrollen die nicht mehr sichtbaren Daten aus dem Speicher entfernen und die sichtbaren Daten nachladen (z.B. Zeile 100 - 250)
Import:
- Daten auf Datenbankebene verarbeiten (SQL-Befehle) oder Zeile für Zeile

Zitat von Harry Stahl:

Zur Erinnerung: Eine 32-Bit-Version kann nicht mehr als 2 GB Arbeitsspeicher in Anspruch nehmen.

Das ist nicht ganz richtig. Mit diesem Flag sind je nach Betriebsystemumgebung bis zu 4 GB Arbeitsspeicher direkt adressierbar.

Delphi-Quellcode:

{$SetPEFlags IMAGE_FILE_LARGE_ADDRESS_AWARE}

{$R *.res}

begin
  Application.Initialize;
{...}