Was ist schneller TComboBox oder TStringlist?

[smart]

Was ist eigendlich schneller, TComboBox oder TStringlist?

[alcaeus]

Nachdem TComboBox.Items ja auch nur eine TStringList ist, ist die Antwort wohl klar. Ich frag mich warum du aber einen Vergleich zw. einem VCL-Control und einer "normalen" Klasse machen willst :gruebel:

Greetz
alcaeus

[smart]

Ganz einfach, ich habe eine sehr lange Stringliste einzulesen und auf meinem Rechner erscheint es so, als ob TComboBox schneller ist.

[Luckie]

So bald die Anzahl der Items so hoch ist, dass die Geschwindigkeit eine Rolle spielen würde, hast du mit Sicherheit einen generellen Designfehler in deiner GUI. Oder was meinst du soll ein Anwender mit mehr als hundert Items in einer Combobox machen?

[malo]

Du kannst ja einfach mal selbst die Zeit messen ;)

[smart]

Natürlich, da hast Du Recht, man kann aber die TComboBox als TStringlist missbrauchen wenn man sie Visible := false setzt.

[stefan2005]

hi
aber ich glaube kaum dass eine ComboBox mit Einer StringList schneller ist als eine StringList alleine, eher umgekehrt !
notfalls könntest du ja einen Array von Strings machen, das könnte vielleicht schneller sein !

cu,
stefan2005

[Binärbaum]

Zitat:

Zitat von smart

Natürlich, da hast Du Recht, man kann aber die TComboBox als TStringlist missbrauchen wenn man sie Visible := false setzt.

Aber das ist wohl kaum Sinn und Zweck einer TComboBox. Wenn es dir nur um das Einlesen von irgendwelchen Daten geht, dann ist TStringList die bessere (und wohl auch schnellere) Wahl.

MfG
Binärbaum

[stefan2005]

hi,
ja es wird sicher auch die schnellere Wahl sein, weil sowas:

Delphi-Quellcode:

type 
  TRecrd = record
    Int : Integer
  End;
var Recrd : TRecrd;
...
Recrd.Int := 1;

ist ja auf keinen Fall schneller wie sowas:

Delphi-Quellcode:

var Int : Integer
...
Int := 1

:wink:
cu,
stefan2005

[smart]

Vielen Dank für Eure Antworten. Ich glaube die Sache mit den Array’s ist die schnellste. Kann man aber Array’s setzen wenn vorher nicht bekannt ist wie viel man braucht ?
@stefan2005 natürlich Du hast Recht.

[phXql]

Zitat:

Zitat von smart

Vielen Dank für Eure Antworten. Ich glaube die Sache mit den Array’s ist die schnellste. Kann man aber Array’s setzen wenn vorher nicht bekannt ist wie viel man braucht ?
@stefan2005 natürlich Du hast Recht.

Ja, dynamische Arrays.. Dann musst du es aber immer um eins vergrößern, und das braucht wieder zeit...

[Luckie]

Zitat:

Zitat von phXql

Dann musst du es aber immer um eins vergrößern, und das braucht wieder zeit...

Wieso denn das? Ich kann doch setlenght mit jedem beliebeighne Wert aufrufen. :gruebel:

[phXql]

Zitat:

Zitat von Luckie

Zitat:

Zitat von phXql

Dann musst du es aber immer um eins vergrößern, und das braucht wieder zeit...

Wieso denn das? Ich kann doch setlenght mit jedem beliebeighne Wert aufrufen. :gruebel:

nein, nicht wegen dem 1s, sondern, wenn man ein array verlängert, wird das ganze array im speicher kopiert, und das braucht seine zeit...

[Luckie]

Dann muss man eben etwas schätzen und das Arry so dimensionieren, dass man es nicht so oft machen muss.

[smart]

Gibt es bei den Array’s eigendlich eine Grenze (wieviel man erzeugen kann)?

[JasonDX]

du kannst dein array füllen bis der speicher voll ist oder (falls das kleiner ist): grenzwert des Integers (2^31 - 1)
falls du das mit erstellen meinst...

[maynard]

Tach...

Ich weiß nicht ab welcher Delphiversion es Int64 gibt ... aber da bleiben dir dann 2^63 - 1 Elemente ... und wenn das nicht reicht müsstest du dir eine eigene Klasse zur Behandlung von Zahlen schreiben bzw. da gibts schon fertige und eine eigene Containerklasse wo du dann am besten die Speicherverwaltung selbst übernimmst und es nicht alles mit SetLentgh machst. Aber ich denke mal soviel Aufwand wird in deinem Fall nicht nötig sein!

MfG

[smart]

Nein, so eine Größe brauche ich natürlich nicht. Die Liste die ich einlesen muss ist so um die 50.000 Zeilen lang und kann erweitert werden. Ich habe eben nach einer Möglichkeit gesucht, diese schnell einzulesen und zu sortieren.

[Binärbaum]

Zitat:

Zitat von smart

Nein, so eine Größe brauche ich natürlich nicht. Die Liste die ich einlesen muss ist so um die 50.000 Zeilen lang und kann erweitert werden. Ich habe eben nach einer Möglichkeit gesucht, diese schnell einzulesen und zu sortieren.

Dann kann man ja vor dem Einlesen die Länge des Arrays auf 50.000 setzen und dann beim Einlesen stets eine Variable hochzählen lassen, die die bisher gelesenen Zeilen zählt. Wenn die Zahl dann 50.000 erreicht hat, kann man die Arraygröße ja nochmal erhöhen. Man müsste aber auch nach dem Einlesen das Array wieder verkleinern, wenn nicht die vollen 50.000 Zeilen benutzt wurden. Das ist dann auf alle Fälle schneller, als wenn man für jede Zeile SetLength aufrufen muss.

MfG
Binärbaum

[Hansa]

Zitat:

Zitat von Luckie

Dann muss man eben etwas schätzen und das Arry so dimensionieren, dass man es nicht
so oft machen muss.

Ist das Dein Ernst ? :shock: Nene, so gehts nicht. Bzw. kann man eine solche Vorgehensweise keinem empfehlen. @Luckie : das hat jetzt mit Dir nichts zu tun, aber schätzen, das geht nicht bei 50.000 Einträgen. Und irgendwas auf false zu setzen (wer war das ? :mrgreen: ) und zweckentfremdet einzusetzen ist es auch nicht.

Deshalb stellen sich erst mal folgende Fragen :

1. ist die Zahl 50.000 nahezu konstant ? Sagen wir mal, zwischen 45.000 und 50.200 ? Falls ja, dann muß man eben nur 5.700 mal ein dynamisches Array abändern oder den Speicher gleich unnötig hoch verbruzeln.

2. Wo kommen die 50.000 Zeilen her ? Von Hand eingegeben wohl nicht. 8) Muß das etwa zeilenweise von der Platte gelesen werden ? Dann bräuchte man sich nicht zu wundern, wenn es dauert.

Deshalb : für so was sind dynamische Datenstrukturen gemacht (verkettete Listen -> Zeiger). Genau für solche Fälle. Fügt man immer nur das ein, was tatsächlich gebraucht wird und schreibt man allgemeingültige Prozeduren dafür, dann ist es fast egal ob es sich um 100 oder 500.000 Einträge handelt.

[Binärbaum]

Zitat:

Zitat von Hansa

...
Deshalb : für so was sind dynamische Datenstrukturen gemacht (verkettete Listen -> Zeiger). Genau für solche Fälle. Fügt man immer nur das ein, was tatsächlich gebraucht wird und schreibt man allgemeingültige Prozeduren dafür, dann ist es fast egal ob es sich um 100 oder 500.000 Einträge handelt.

Ja, schon möglich aber:

Zitat:

Zitat von smart

Ich habe eben nach einer Möglichkeit gesucht, diese schnell einzulesen und zu sortieren.

Das Einlesen ist ja noch nicht das Problem, da spielt es auch kaum eine Rolle, ob man (dynamische) Arrays oder verkettete Listen verwendet, da beim Einlesen höchstwahrscheinlich die Festplatte der Flaschenhals sein wird.
Allerdings sind Arrays für das Sortieren die bessere Wahl, da der Zugriff auf die einzelnen Elemente über den Index relativ schnell erfolgt. Bei verketteten Listen hingegen muss man immer erst die Liste vom Anfang an Element für Element durchlaufen bis man beim jeweiligen Element angekommen ist. Und bei ca. 50.000 Einträgen ist das schon ein erheblicher Nachteil, da man da im Mittel 25.000 Einträge durchlaufen muss, um auf ein beliebiges Element zuzugreifen (bei doppelt verketteten Listen wären es zwar "nur" noch 12.500, aber das ist auch noch zu viel).
Fazit: Beim Sortieren sind Array eindeutig schneller als verkettete Listen.

MfG
Binärbaum

[Edit]
Hier mal ein Beispiel, wie die Prozedur zum Einlesen aussehen könnte:

Delphi-Quellcode:

procedure Einlesen(dateiname: string; var arr: array of string; anzahl: Cardinal= 5000);
var zeilen, gr: Integer;
    dat: TextFile;    
begin
  gr:=anzahl;
  SetLength(arr, gr);
  zeilen:= 0;
  try
    Assign(dat, dateiname);
    Reset(dat); 
    while not Eof(dat) do begin
      zeilen:= zeilen+1;
      if zeilen>gr then begin 
        SetLength(arr, High(arr)+1001);
        gr:= High(arr)+1;
      end;
      ReadLn(dat, arr[zeilen-1]);
    end;
  finally
    Close(dat);
  end;
  SetLength(arr, zeilen);
end;

Zur Erklärung der Parameter:
dateiname ist der Name der Textdatei, die ausgelesen werden soll.
anzahl ist die geschätzte Anzahl der Zeilen (hier: 5000 als Standard).
arr ist der Array in den die Datei zeilenweise eingelesen wird.

Ein Beispielaufruf könnte dann so aussehen:

Delphi-Quellcode:

Einlesen('C:\Pfad\name.txt', meinArray, 2000);
//oder
Einlesen('C:\Pfad\name.txt', meinArray);
//entspricht Einlesen('C:\Pfad\name.txt', meinArray, 5000);

[/Edit Ende]

[Hansa]

Zitat:

Zitat von Binärbaum

...Fazit: Beim Sortieren sind Array eindeutig schneller als verkettete Listen...

Verkettete Liste, das war ein Beispiel. Sonst nichts. Bei größeren Datenstrukturen macht man so was mit einem Baum. Oder eventuell mit einem Ring, sofern eine Richtung darstellbar ist. Dann braucht man nämlich den Zeiger von Position 49999 nur noch eins weiter zu setzen, um wieder am Anfang zu sein. Und selbst das ist egal. Man merkt sich sowieso den Anfang, das Ende usw.

Dann geht es nur noch darum, den Zeiger auf eine gewisse Position zu setzen. Und das geschieht mit minimalem Aufwand und geringstem Speicherbedarf. Ein Array (vor allem ein dynamisches) wird wohl intern auch in solche Strukturen zerlegt und dementsprechend behandelt.

Vielleicht taucht negaH noch auf, dann kann er ja mal erklären, wieviele Zugriffe man z.B. im DB Bereich braucht, um einen genau defininierten Datensatz aus einer Isam mit 50.000 Datensätzen herauszufischen. Wer will, kann ja mal schätzen und wird sich wohl wundern.

Zurück zur Frage : wer nicht weiß, was dynamische Strukturen sind, der soll sie eben nicht benutzen. Was bei der Combobox schneller sein soll, als bei der Stringliste ist mir rätselhaft. Ohne Beantwortung meiner beiden Fragen läßt sich schwer ein Tip geben, was jetzt wo gemacht werden soll/muß.

@Binärbaum : das sehe ich ja jetzt erst. :shock: Wo hast Du den Namen her ? :mrgreen:

[Sharky]

Hai,

ich habe da eben mal etwas herum gespielt. Ich habe zum einen eine TComboBox auf der Form und eine TListBox. Ausserdem noch eine zur Laufzeit erzeugte TStringList. In alle drei Objekte habe ich dann eine Textdatei mit 50.000 Zeilen geladen (ohne sortierung).
Hier mal die Zeiten:

Code:

*  TStringList :      63 ms
*  TComboBox   :  50.750 ms
*  TListBox    :  51.200 ms

Beim einlesen ist die TStringList also die schnellste Variante.

[alcaeus]

Hallo Sharky,

hast du die ComboBox auch unsichtbar gemacht? Wenn die Box sichtbar ist dann geht doch viel Zeit fuer die Anzeige drauf.

Greetz
alcaeus

[Sharky]

Zitat:

Zitat von alcaeus

... Wenn die Box sichtbar ist dann geht doch viel Zeit fuer die Anzeige drauf....

Hai alcaeus,

wenn ich die TCombobox.Visible := False setze sparte ich im Schnitt ca. 120 ms.
Es sieht so aus als wäre einfach bei der implementierung des LoadFromFile bei der TComboBox wesentich mehr overhead vorhanden.

[alcaeus]

Zitat:

Zitat von Sharky

wenn ich die TCombobox.Visible := False setze sparte ich im Schnitt ca. 120 ms.
Es sieht so aus als wäre einfach bei der implementierung des LoadFromFile bei der TComboBox wesentich mehr overhead vorhanden.

Das ueberrascht mich jetzt, ich hab naemlich in den Sourcen nachgesehn, und TStringList.LoadFromFile sowie TComboBox.Items.LoadFromFile gehn beide auf TStrings.LoadFromFile, und dort wird mit TStrings.LoadFromStream gearbeitet. Von daher kann es nicht der Overhead sein. Hast du das Ausblenden auch mit der ListBox probiert? Evtl. kann auch ein BeginUpdate helfen.

Greetz
alcaeus

[Sharky]

Zitat:

Zitat von alcaeus

... Hast du das Ausblenden auch mit der ListBox probiert? Evtl. kann auch ein BeginUpdate helfen.

Ein Begin/EndUpdate war auch mein gedanke. Hat aber nichts gebracht. Und auch bei der ListBox ist es egal ob Visible oder nicht.
Es ist echt interesant warum die TStringList bei mir da viel schneller ist.
Hast Du auch einmal einen Test gemacht?

[Edit]Ich habe mein Testprogramm man angehängt

[alcaeus]

Hallo Sharky,

hier mal meine Ergebnisse:

Code:

Added 50000 items to visible Listbox in 730 ms 
Added 50000 items to visible Listbox in 860 ms (using Begin/EndUpdate)
Added 50000 items to invisible Listbox in 931 ms 
Added 50000 items to invisible Listbox in 842 ms (using Begin/EndUpdate)
Added 50000 items to visible Combobox in 1320 ms 
Added 50000 items to visible Combobox in 1081 ms (using Begin/EndUpdate)
Added 50000 items to invisible Combobox in 1281 ms 
Added 50000 items to invisible Combobox in 1151 ms (using Begin/EndUpdate)
Added 50000 items to Stringlist in 60 ms 
Added 50000 items to Stringlist in 61 ms (using Begin/EndUpdate)


Added 100000 items to visible Listbox in 1703 ms 
Added 100000 items to visible Listbox in 1852 ms (using Begin/EndUpdate)
Added 100000 items to invisible Listbox in 2083 ms 
Added 100000 items to invisible Listbox in 2032 ms (using Begin/EndUpdate)
Added 100000 items to visible Combobox in 2423 ms 
Added 100000 items to visible Combobox in 2382 ms (using Begin/EndUpdate)
Added 100000 items to invisible Combobox in 2412 ms 
Added 100000 items to invisible Combobox in 2073 ms (using Begin/EndUpdate)
Added 100000 items to Stringlist in 49 ms 
Added 100000 items to Stringlist in 100 ms (using Begin/EndUpdate)

Die Testdateien enthielten einfach die Zahlen 1-50000 bzw. 100000, ich hatte sie zuvor per SaveToFile reingeschrieben. Das Begin/EndUpdate war nicht in der Zeitmessung enthalten, mich ueberraschen die Ergebnisse also schon. Was auch sehr eigenartig ist, ist dass die StringList bei 100000 Zahlen schneller laeuft als bei 50000 :shock:

Bei deinem Test gabs die folgenden Ergebnisse:

Code:

TStringList: 110
TComboBox (sichtbar): 31616
TComboBox (unsichtbar): 30103
TListBox (sichtbar): 30704
TListBox (unsichtbar): 30724

Die Ergebnisse sind durchaus interessant...

Greetz
alcaeus

[Sharky]

Hai alcaeus,

ein Geheimniss das es zu lösen gilt ;-)

P.S.: Das deine Ergebnisse schneller sind dürfte daran liegen das ich durch meinen "Test-String" jede Zeile verlängert habe.

[SirThornberry]

der geschwindigkeitsverlust liegt in der schlechten umsetzung der Darstellung. Für unser Newsletterprogramm hab ich früher eine normales TListView genutzt (mit Beginupdate-EndUpdate). Damit hat das programm über 2 Minuten geladen. Inzwischen haben wir eine Skinbare Listview programmiert, man müsste also eigentlich von längerne Ladezeiten ausgehen weil ja noch hintergrundbilder etc. dazu kommen. Ergebnis ist aber das mit der neuen Skinbaren Listview das Programm in weniger als 10 Sekunden startet.

Allerdings haben wir auch darauf verzichtet das ganze über TStringlist umzusetzen beim laden, da bei dieser variante immer erst die Zeilenumbrüche gesucht werden müssen. Wir haben einfach immer die länge der zeile und dahinter die eigentliche Zeile gespeichert. Somit kann man beim einlesen einfach mit Stream.Read gleich die gesamte zeile lesen ohne sie später nochmal zu zerlegen müssen.

Manchmal muss man eben einfach das Rad neu erfinden um es wirklich rund zu bekommen.

[Die Muhkuh]

Was mich jetzt wundert:

Warum brauchen die StringList, etc. mit BeginUpdate und EndUpdate länger, als ohne?

[SirThornberry]

weil bei LoadFromFile/LoadFromStream intern schon ein Beginupdate/Endupdate ausgeführt wird. Und wenn man dann zusätzlich noch ein Beginupdate/Endupdate um das ganze schreibt sind das paar Anweisungen mehr.

[smart]

Guten Morgen!
Zunächst mal vielen Dank, dass Ihr euch so eine Mühe gebt. Die Liste hat tatsächlich 50.000 Einträge. Es können sogar noch welche hinzukommen. Dabei handelt es sich um eine Warenliste. Natürlich gibt es Wege so etwas besser zu lösen(Datenbank), aber das Programm das diese Liste erzeugt ist ein Fremdes Programm.

Das Beispiel von Binärbaum habe ich mal getestet. Das Sortieren und/oder Vergleichen erscheint mir bei Arrays einfacher. Allerdings bin ich noch Delphi- Anfänger und kenne noch nicht viele Lösungswege.

[Jens Schumann]

Zitat:

Zitat von stefan2005

hi,
ja es wird sicher auch die schnellere Wahl sein, weil sowas:

Delphi-Quellcode:

type 
  TRecrd = record
    Int : Integer
  End;
var Recrd : TRecrd;
...
Recrd.Int := 1;

ist ja auf keinen Fall schneller wie sowas:

Delphi-Quellcode:

var Int : Integer
...
Int := 1

:wink:
cu,
stefan2005

Das halte ich für ein Gerücht. Beide Fälle müssen gleich schnell sein.
Ob Recrd.Int oder Int in beiden Fällen stehen die Adressen der Variablen eindeutig fest.

[alcaeus]

Zitat:

Zitat von smart

Das Beispiel von Binärbaum habe ich mal getestet. Das Sortieren und/oder Vergleichen erscheint mir bei Arrays einfacher.

Folgender Test: Zahlen von 50000 bis 1 zeilenweise in Datei schreiben, dann in StringList laden. Anschliessend habe ich die Liste mit .Sort sortiert (WorstCase, da genau umgekehrte Reihenfolge). Die Zeit fuer beide Aktionen betrug grad mal 551 ms (im vergleich zu nur Laden=60ms). Jetzt kommt es natuerlich auf die Laenge jeder Zeit an. Es waere vielleicht hilfreich, wenn du eine "Durchschnittszeile" aus der Datei zeigen koenntest, dann koennen wir mal sehn wie lange das mit den Zeilen braucht.

Greetz
alcaeus

[Jens Schumann]

Zitat:

Zitat von smart

... Das Sortieren und/oder Vergleichen erscheint mir bei Arrays einfacher. Allerdings bin ich noch Delphi- Anfänger und kenne noch nicht viele Lösungswege.

Wenn Du die Daten in ein Array einlesen möchtest bleibt Dir nur die Wahl eines dyn. Array's.
Jetzt musst Du aber aufpassen. Wenn Du die Daten "direkt" im Array speicherst werden die Daten selbst beim Sortieren im Array hin und her kopiert. Das kann bei Strings ziemlich lange dauern. Deshalb solltest Du im Array lediglich Zeiger auf die Daten speichern. Beim Sortieren werden dann nur die Zeiger kopiert. Das geht schon wesentlich schneller. Wenn Du das alles implementiert hast, hast Du ungefähr die Funktionalität von TList nachgebildet. Deshalb empfehle ich Dir nimm TList. Mit der Methode TList.Sort bekommst Du eine Sortierfunktion dazu.

Wenn Du es so schnell wie möglich haben möchtest müsstest Du auf verkette Listen ausweichen.

[smart]

Also, so sehen die Zeilen aus.

Delphi-Quellcode:

2210019000009;Feingetriebe AS5;179,00

Warennummer, Bezeichnung, Preis.

[alcaeus]

Ich hab grad mal die Zeile bei den Zahlen angehaengt (also so: 35924 2210019000009;Feingetriebe AS5;179,00), und das Laden und sortieren hat grad mal 1 Sekunde gedauert. Ich schaetze das ist eine vertretbare Zeit... ComboBox und ListBox habe ich nicht getestet, aber das wird wahrscheinlich viel laenger dauern. Wichtig ist aber, zuerst die Elemente zu laden, und anschliessend zu sortieren. Wenn ich naemlich Sorted auf True setze, und anschliessend lade, dann dauert die Story ganze 4.5 Sekunden.

Greetz
alcaeus

[Hansa]

eure Ergebnisse sind echt verblüffend. Insbesondere das mit dem Visible. Vor einiger Zeit hatte ich folgenden Effekt (allerdings bei einem Stringgrid) : 9 Felder aus 2500 Datensätze in 9 Spalten einlesen : 115 Sek. Diese Zeit wäre sogar noch fast egal gewesen, weil es nur um einen Ausdruck ging.

Trotzdem kam es mir zu langsam vor und ich habe folgendes gemacht : vor Lesen der Daten Stringgrid.Hide und danach Stringgrid.Show. Alles andere blieb gleich. Und sieh an, das dauerte noch ganze 1,2 Sek. :shock: 99 % der Zeit wurden also im ersten Fall nur für die Anzeige im Stringgrid gebraucht ! Und es kam mir so vor, als hänge das ganze hauptsächlich von der Menge der auszugebenden Zeichen ab. Denn bei gleichen Daten hatte ich nur eine Spalte befüllt und direkt angezeigt und das dauerte ca. 10-20 Sek. Bei 50.000 Zeilen muß das doch mehr ausmachen, als ein paar Millisek. Unterschied, ob sichtbar oder nicht ? Bei Alcaeus war das sichtbare ja einmal sogar schneller. 8)

[Hallo_Thomas]

verkehrt