Gleich am Anfang: Dieser Post könnte etwas länger werden - daher bin ich jedem dankbar, der sich diesem Programmierproblem animmt - Ich brauche keine code-lösungen o.ä. sondern nur Hinweise

Ich arbeite im Moment an einen code-editor für verschiedene Programmiersprachen (u.a. C). Dieser Code-Editor soll natürlich die Möglichkeit des Autovervollständigen haben. Hier beginnt für mich ein großes Problem.

Bei einer durchschnittsgröße der Code-Projekte von mehreren 10.000 zeilen kann es sehr schnell vorkommen, das beim Parsing Vorgang mehrere tausend Objekte (präprozessoren, funktionsdefinitionen usw.) erstellt werden.
Diese speicher ich im Moment alle in mehreren Listen des typs boost::bimap< NAME_DES_OBJEKTES, SET_OF< POINTER DES OBJEKTES >; (für jeden Typ wie: Datentypen, Variablen, Funktionen usw. eine Liste).
Problematisch wird es nun bei der Geschwindigkeit der Auto-Complete-Vorschläge.

Jetzige Lösung: Der User gibt zum Beispiel "ifd" ein. Intern wird die Liste der 10.000 Objekte durchsucht und mit hilfe der Levenshtein distanz berechnet wie ähnlich der Name des Objektes zu dem Input ist. Bei ausreichend niedriger Distanz wird das Objekt der Auto-Complete liste hinzugefügt.

Das große Problem ist, dass dies einfach zu langsam ist. Bei ca. 10.000 (und das ist leider noch niedrig gegriffen) Objekten einen Levenshtein Algorithmus durchzuführen ist einfach zu viel verlangt für einen coder der 5 Zeichen in der Sekunde eingeben kann.

Daher hier meine eigentliche Frage: Wie würdet ihr das machen? Die Daten "anders" (wenn ja - wie?) speichern? Andere Algorithmen zur Ähnlichkeitsprüfung benutzen? Externe Tabellenlibraries benutzen (SQLITE o.ä.) für SELECT Abfragen?

Davon abgesehen: was würdet ihr machen, wenn der User z.B. erst ein "b" eingeben hat? Nach Levenshtein distanz ergibt hier jeder zweite Objekt natürlich einen Treffer. Nur welche der 5.000 Ergebnisobjekte sollte man anzeigen in der Auto-Complete liste?

Vielen Dank für das lesen und für jeden Ratschlag,
mit freundlichen Grüßen,
Timo Stark

Auto-Vervollständigung erst anzeigen, wenn man eine bestimmte Anzahl (z.b.) 3 Zeichen hintereinander eingegeben hat. Ansnsonsten kann man bei kurzen Eingaben ja nur die Dinge anzeigen, die mit dem getippten anfangen.

Vielleicht ist die Levenstein-Distanz auch etwas overpowered? Du könntest zb nur Zeichenketten anzeigen, die das eingetippte genau enthalten. Oder du verwendest noch Abkürzungen für Bezeichner:

IchBinCamelCase könnte bspw. alse ibcc eingegeben und vorgeschlagen werden. oder ich_bin_mit_unterstrichen als ibmu.

Erstmal vielen Dank für die beiden Antworten.
Die Levenshtein distance ist an sich eine sehr genaue Möglichkeit um viele verschiedene mögliche Tippfehler abzufangen.
Vielleicht ist das auch nicht zu 100% richtig rüber gekommen. Im Moment wird bei weniger als 3 eingegebenen Zeichen nicht mit der Levenshtein Distanz Methode gearbeitet.

Eine Frage habe ich an euch beide: In wie weit stellt ihr euch vor, dass die Überprüfung bei längeren Strings schneller ist? Beispiel:

Bei weniger als 6 Buchstaben wird nur ein fehler akzeptiert, ab 6 zwei Fehler
Eingabe: HetOpem, Ausgabe: --- ( GetOpenFilename wird nicht angezeigt, da zwei fehler)
Eingabe: HetOpemFileN, Ausgabe: GetOpenFileName

Da es diese Abstufungen mit Anzahl der Buchstaben m. M. geben muss (desto mehr eingegeben wird desto mehr Fehler sind erlaubt), muss so mehrmals der name aller 10.000 objekte auf einen längeren String überprüft werden. Ist das performanter als bei kurzen Strings? (ich speicher bei kurzen strings natürlich auch nicht alle 5000 ergebnisse sondern nur die ersten 15).

Daher bitte ich um weitere Anregungen, wie ich so große listen performant nach String-Distanzen (ich bin hier auch weiterhin natürlich für andere Vorschläge offen) durchsuchen kann? (Und welche speicherform die liste hier am besten haben sollte).

Es gibt in SQLLITE im SELECT Befehl SOUNDEX ( SELECT * FROM _objects_ INTO .. WHERE SOUNDEX(object_name) = SOUNDEX(input) ) - Hat hiermit jemand Erfahrungen (bezgl. Performance?

Vielen dank schon mal für die Antworten,
Timo Stark

* We can adapt the algorithm to use less space, O(m) ...
* If we are only interested in the distance if it is smaller than a threshold k ...
* By examining diagonals instead of rows, and by using lazy evaluation, we can find the Levenshtein distance in O(m (1 + d)) time ...

Hast du soetwas wie early out in Betracht gezogen unter Verwendung von oberer und unterer Schranke?

* It is always at least the difference of the sizes of the two strings.

D.h. ist dein String 4 Zeichen lang und dein Threshold 5, dann brauchst du alle Strings laenger als 9 in deiner Map gar nicht erst betrachten.

Schon ueber Parallelisierung nachgedacht? Die Rechnung String a1 zu String b1 kann unabhaengig von der Berechnung String a1 zu String b2 durchgefuehrt werden.

Da es diese Abstufungen mit Anzahl der Buchstaben m. M. geben muss

Das wuerde ich erst machen, wenn alle anderen Optionen ausgereizt sind. Alternativ kannst du dir auch den Smith-Waterman-Algorithmus fuer Sequenzalignment ansehen.

Early-Out ist bereits implementiert. Ich bin mir allerdings ganz und gar nicht sicher warum ich noch nicht auf sowas wie OpenMP gekommen bin - das eignet sich ja geradezu perfekt dazu.

Werde hier mal einige Speed-Tests machen.

Vielen Dank für den Hinweis,
Ich melde mich bei späteren Fragen zu diesem Thema,
Grüße,
Timo Stark

PS: Meinst Smith-Waterman-Algorithmus ist tatsächlich performanter? Die Komplexität & Speicherverbrauch sind gleich / ähnlich. Nur die Implementation sieht recht komplex aus

Meinst Smith-Waterman-Algorithmus ist tatsächlich performanter? Die Komplexität & Speicherverbrauch sind gleich / ähnlich. Nur die Implementation sieht recht komplex aus

Keine Ahnung, aber beim Sequenzalignment in der Bioinformatik, wenn man mehrere Terrabyte an Daten vergleichen muss, sollte es schon recht fix gehen. Ich verstehe auch nicht, warum es bei dir unzureichend lange braucht. Ist deine Implementation eher schlecht? Wie lange dauert es denn, die Distanz von "idf" (oder was auch immer) mit 10.000 anderen Strings zu berechnen (ohne early-out)?

gerade bei vervollständigungen kann man davon ausgehen dass die ersten x zeichen korrekt sind: dh, zB wenn das erste Zeichen nicht identisch ist, kann man gleich den vergleich abbrechen. oder aber andere primitivere tests laufen lassen, die ungenau aber eben schnell sind. und nur wenn der ungenaue test gemachtet hat, dann den teuren test laufen lassen.

uU macht es auch sinn das charset zu verringern. zB d und t gleichzubehandeln um so die komplexität der vergleiche zu reduzieren (auf kosten der treffer qualität natürlich).

lg lolo

das teil das du suchst heißt trixy
http://de.wikipedia.org/wiki/Trie

Mehr Details bitte.
trixy?

Ich werde das mit den Parallel-Programming versuchen & denke ich wie ShadeOfMind vorgeschlagen hat davon ausgehen das bei weniger als ~4 eingegebenen Zeichen, die ersten Buchstaben für globale Objekte korrekt sind. (Für lokale (in der Umgebung definierte) Objekte wird diese einschränkung nicht gelten, da höhere Priroität ist).

Ich bedanke mich vielmals für die gute Hilfe hier in diesem Forum
Viele Grüße,
Timo

PS: Wegen Trixy: Das habe ich mir gerade mal angeschaut - sieht von der Basis her nicht schlecht aus, hat aber leider die falsche Lizenz für mich.