Effiziente Trie-Implementierung für Unicode-Strings

Ich habe nach einer effizienten String-Trie-Implementierung gesucht. Meistens habe ich folgenden Code gefunden:

Referenzielle Implementierung in Java (per Wikipedia)

Ich mag diese Implementierungen aus zwei Gründen nicht:

1. Sie unterstützen nur 256 ASCII-Zeichen. Ich muss Dinge wie Kyrillisch behandeln.
2. Sie sind extrem speichereffizient.

Jeder Knoten enthält ein Array mit 256 Referenzen, dh 4096 Byte auf einem 64-Bit-Computer in Java. Jeder dieser Knoten kann bis zu 256 Unterknoten mit jeweils 4096 Byte Referenzen haben. Ein vollständiger Trie für jede ASCII 2-Zeichenfolge würde also etwas mehr als 1 MB erfordern. Drei Zeichenketten? 256 MB nur für Arrays in Knoten. Und so weiter.

Natürlich habe ich nicht vor, alle 16 Millionen drei Zeichenfolgen in meinem Trie zu haben, also wird viel Platz nur verschwendet. Die meisten dieser Arrays sind nur Nullreferenzen, da ihre Kapazität die tatsächliche Anzahl der eingefügten Schlüssel bei weitem überschreitet. Und wenn ich Unicode hinzufüge, werden die Arrays noch größer (char hat 64k-Werte anstelle von 256 in Java).

Gibt es Hoffnung, einen effizienten Versuch für Saiten zu machen? Ich habe einige Verbesserungen gegenüber diesen Arten von Implementierungen in Betracht gezogen:

• Anstatt ein Array von Referenzen zu verwenden, könnte ich ein Array vom primitiven Integer-Typ verwenden, das in ein Array von Referenzen auf Knoten indiziert, deren Größe nahe an der Anzahl der tatsächlichen Knoten liegt.
• Ich könnte Strings in 4-Bit-Teile aufteilen, was Knoten-Arrays der Größe 16 auf Kosten eines tieferen Baums ermöglichen würde.

Wofür benutzt du diesen Versuch? Was ist die Gesamtzahl der Wörter, die Sie halten möchten, und wie spärlich sind ihre konstituierenden Charaktere? Und am wichtigsten ist, ist ein Versuch überhaupt angemessen (im Vergleich zu einer einfachen Karte des Präfixes zur Liste der Wörter)?

Ihre Idee einer Zwischentabelle und des Ersetzens von Zeigern durch Indizes funktioniert, vorausgesetzt, Sie haben einen relativ kleinen Satz kurzer Wörter und einen spärlichen Zeichensatz. Andernfalls besteht die Gefahr, dass der Platz in Ihrer Zwischentabelle knapp wird. Und wenn Sie nicht nur einen extrem kleinen Satz von Wörtern betrachten, sparen Sie nicht wirklich so viel Platz: 2 Bytes für einen Kurzschluss gegenüber 4 Bytes für eine Referenz auf einem 32-Bit-Computer. Wenn Sie mit einer 64-Bit-JVM arbeiten, sind die Einsparungen höher.

Ihre Idee, die Zeichen in 4-Bit-Blöcke aufzuteilen, wird Ihnen wahrscheinlich nicht viel ersparen, es sei denn, alle erwarteten Zeichen befinden sich in einem äußerst begrenzten Bereich (möglicherweise in Ordnung für Wörter, die auf US-ASCII in Großbuchstaben beschränkt sind, wahrscheinlich nicht mit einem allgemeinen Unicode-Korpus ).

Wenn Sie einen spärlichen Zeichensatz haben, ist a HashMap<Character,Map<...>>möglicherweise die beste Implementierung. Ja, jeder Eintrag wird viel größer sein, aber wenn Sie nicht viele Einträge haben, erhalten Sie einen Gesamtsieg. (als Randnotiz: Ich fand es immer lustig, dass der Wikipedia-Artikel über Versuche ein Beispiel zeigte - vielleicht immer noch -, das auf einer gehashten Datenstruktur basiert und die räumlichen / zeitlichen Kompromisse dieser Wahl völlig ignorierte)

Schließlich möchten Sie vielleicht einen Versuch ganz vermeiden. Wenn Sie sich ein Korpus normaler Wörter in einer menschlichen Sprache ansehen (10.000 Wörter im aktiven Gebrauch, mit Wörtern von 4 bis 8 Zeichen Länge), sind Sie wahrscheinlich mit a viel besser dran HashMap<String,List<String>, wobei der Schlüssel das gesamte Präfix ist.

Wenn Sie die Zeichenfolgen in UTF8 codieren, können Sie den Standard-256-Verzweigungsversuch verwenden und trotzdem Unicode-kompatibel sein

Außerdem sollten Sie beachten, dass nur etwa 70 Zeichen von den möglichen 128 ASCII-Zeichen (die alle in UTF8 auf 1 Byte codiert sind) am stärksten gefunden werden, die Sie dafür optimieren können (z. B. die allgemeinen Digraphen anstelle der nicht verwendeten Steuerzeichen )