Suche in TStrings optimieren

[Schwedenbitter]

Zitat von jfheins:

Mooooment!

Dass sich die Liste ändern kann während der Algorithmus läuft war so nicht erwähnt. Und es wäre ein fetter Designfehler.

Asche auf mein Haupt
Das mit dem Designfehler ist so eine Sache. Die Software ist ca. 2 Jahre alt. Das Grundkonzept habe ich mir nicht selbst ausgedacht, sondern es stammt von hier. Es läuft problemlos über die genannte Zeit. Das einzige Problem, welches ich seither habe, ist die Frage, ob man Nachrichten an mehrere Clients schicken kann, wenn diese nicht ausgewählt wurden. Auch das klappt vom Prinzip.
Der "Designfehler" mit der sich ändernden Liste ist mir während dieses Threads aufgefallen. Das ist m.E. schon eine Leistung, wenn man nicht Informatik studiert hat und einem Fehler auffallen, ohne dass das Programm bereits geschrieben ist, läuft und diese zum Problem werden...
Das serverseitige Verschicken ohne Dublikate kommt nicht in Betracht. Zum einen möchte ich alle Benutzer explizit sehen. Sie unterscheiden sich z.B. danach, ob ein Benutzer längere Zeit hindurch den Rechner nicht benutzt hat. Admins können andere tolle Sachen machen als "normale" Benutzer ... Zum anderen soll das mit dem Senden an Dublikate eine zusätzliche Funktion und nicht der Standard werden.

alzaimar hat im Grunde recht - die Ausgangsfrage (ohne das lästige Problem sich ändernder Listen) wurde gelöst.

Ich denke mir mal eine neue Methode aus, die Suche sicher laufen zu lassen und werde das dann nur der Vollständigkeit halber später hier mal posten. Um die 2. Liste werde ich dabei wohl nicht herumkommen.

Danke an alle Mitdenkenden für die Unterstützung

Alex

[jfheins]

Zitat von Schwedenbitter:

Asche auf mein Haupt

Nun mal nicht so vorschnell ... die schöne Asche

Zitat:

Das mit dem Designfehler ist so eine Sache. Die Software ist ca. 2 Jahre alt. Das Grundkonzept habe ich mir nicht selbst ausgedacht, sondern es stammt von hier. Es läuft problemlos über die genannte Zeit. Das einzige Problem, welches ich seither habe, ist die Frage, ob man Nachrichten an mehrere Clients schicken kann, wenn diese nicht ausgewählt wurden. Auch das klappt vom Prinzip.
Der "Designfehler" mit der sich ändernden Liste ist mir während dieses Threads aufgefallen. Das ist m.E. schon eine Leistung, wenn man nicht Informatik studiert hat und einem Fehler auffallen, ohne dass das Programm bereits geschrieben ist, läuft und diese zum Problem werden...

Es ist ja noch nicht geklärt ob es diesen "Designfehler" überhaut gibt. Ichhabe ja gesagt: "es wäre ein fetter Designfehler".
Ich habe mir gerade das Tutorial mal angeguckt. Da steht nichts von Thread bis auf das Ende, da steht, dass alles über den Hauptthread abgewickelt wird. Wenn sich dein Programm an dem Tutorial orientiert, dann können also keine anderen Threads in der Liste herumpfuschen. (wenn du nicht weist, was Threads sind, hast du wahrscheinlich keine Threads programmiert)

Und solange es keine anderen Threads gibt, kannst du auch sicher sein dass die Liste nicht geändert wird. Weil wenn irgendein Ereignis geschieht, dass veranlassen würde das sich die Liste ändert muss dieses Ereignis warten bis das Programm Zeit findet, es zu bearbeiten. Und somit kann das Ändern der Liste erst nach dem Senden der Nachricht erfolgen.

Mein Fazit ist also: Während der Code läuft kann sich die Liste nicht ändern

@alzaimar: Ich meinte die Anzahl der Vergleiche - Komplexität war vll. das falsche Wort. Das O() habe ich ja schon weggelassen. Dass die Komplexität lienar ist hatte ich ja weiter oben schon gesagt. Danke

[Schwedenbitter]

Zitat von jfheins:

[...]
Wenn sich dein Programm an dem Tutorial orientiert, dann können also keine anderen Threads in der Liste herumpfuschen. (wenn du nicht weist, was Threads sind, hast du wahrscheinlich keine Threads programmiert)
[...]
Weil wenn irgendein Ereignis geschieht, dass veranlassen würde das sich die Liste ändert muss dieses Ereignis warten bis das Programm Zeit findet, es zu bearbeiten. Und somit kann das Ändern der Liste erst nach dem Senden der Nachricht erfolgen.

Ja. Ich wollte nicht das Rad neu erfinden und bin daher strikt nach Anleitung vorgegangen. Ich habe das ganze nur immens aufgebohrt.

Ich programmiere schon mit Threads.
Allerdings ging ich davon aus, dass Ereignisse auch ohne Threads de facto zeitgleich ausgelöst werden und dann abgearbeitet werden können. Kommt eine neue Liste, wird - vom Server gesteuert - ein Ereignis ausgelöst, was diese Liste einfach in die TListBox einträgt.
Wenn ich das jetzt richtig verstehe, würde das Ereignis aber warten müssen, bis mein Sendevorgang beendet ist? -> wieder was dazu gelernt. Das beutet dann aber auch, dass ich an möglichst keiner Stelle im Programm ein Application.Processmessages; aufrufen darf, oder?

Zitat von jfheins:

Und solange es keine anderen Threads gibt, kannst du auch sicher sein dass die Liste nicht geändert wird.

Nur auf dem Server gibt es welche. Aber der ist vom Code/Problem nicht betroffen.

Mein Fazit lautet also:
Ich kann den Code so verwenden und muss nicht meine Idee mit der 2. Liste weiter verfolgen.

Gruß und abermals Danke für die Aufklärung, Alex

[jfheins]

Zitat von Schwedenbitter:

Ja. Ich wollte nicht das Rad neu erfinden und bin daher strikt nach Anleitung vorgegangen. Ich habe das ganze nur immens aufgebohrt.

Ich programmiere schon mit Threads.
Allerdings ging ich davon aus, dass Ereignisse auch ohne Threads de facto zeitgleich ausgelöst werden und dann abgearbeitet werden können. Kommt eine neue Liste, wird - vom Server gesteuert - ein Ereignis ausgelöst, was diese Liste einfach in die TListBox einträgt.
Wenn ich das jetzt richtig verstehe, würde das Ereignis aber warten müssen, bis mein Sendevorgang beendet ist? -> wieder was dazu gelernt. Das beutet dann aber auch, dass ich an möglichst keiner Stelle im Programm ein Application.Processmessages; aufrufen darf, oder?

Ja, genau. Ein Thread kann immer nur an einer Stelle im Code zugleich arbeiten. Dafür gibt es ja die MessageQueue, die die Nachrichten puffert und dafür sorgt das alles schön nacheinander abgearbeitet wird. Diesen Fluss kann man mit Application.ProcessMessages unterbrechen, aber dann kann man sich böse Konsequenzen einhandeln