Implementación eficiente de Trie para cadenas unicode

He estado buscando una implementación eficiente de String trie. Principalmente he encontrado un código como este:

Implementación referencial en Java (según wikipedia)

No me gustan estas implementaciones principalmente por dos razones:

1. Solo admiten 256 caracteres ASCII. Necesito cubrir cosas como cirílico.
2. Son extremadamente ineficientes de memoria.

Cada nodo contiene una matriz de 256 referencias, que son 4096 bytes en una máquina de 64 bits en Java. Cada uno de estos nodos puede tener hasta 256 subnodos con 4096 bytes de referencias cada uno. Por lo tanto, un Trie completo para cada cadena de caracteres ASCII 2 requeriría un poco más de 1 MB. Tres cadenas de caracteres? 256 MB solo para matrices en nodos. Y así.

Por supuesto, no tengo la intención de tener 16 millones de cadenas de tres caracteres en mi Trie, por lo que se desperdicia mucho espacio. La mayoría de estas matrices son solo referencias nulas, ya que su capacidad supera con creces el número real de claves insertadas. Y si agrego unicode, las matrices se vuelven aún más grandes (char tiene valores de 64k en lugar de 256 en Java).

¿Hay alguna esperanza de hacer un trie eficiente para cuerdas? He considerado un par de mejoras sobre este tipo de implementaciones:

• En lugar de usar una matriz de referencias, podría usar una matriz de tipo entero primitivo, que se indexa en una matriz de referencias a nodos cuyo tamaño es cercano al número de nodos reales.
• Podría dividir cadenas en partes de 4 bits que permitirían matrices de nodos de tamaño 16 a costa de un árbol más profundo.

¿Para qué estás usando este trie? ¿Cuál es el número total de palabras que planea mantener y cuál es la escasez de sus caracteres constitutivos? Y lo más importante, ¿es apropiado incluso un trie (versus un simple mapa de prefijo a la lista de palabras)?

Su idea de una tabla intermedia y el reemplazo de punteros con índices funcionará, siempre que tenga un conjunto relativamente pequeño de palabras cortas y un conjunto de caracteres disperso. De lo contrario, corre el riesgo de quedarse sin espacio en su tabla intermedia. Y a menos que esté viendo un conjunto de palabras extremadamente pequeño, realmente no ahorrará tanto espacio: 2 bytes para un corto versus 4 bytes para una referencia en una máquina de 32 bits. Si está ejecutando una JVM de 64 bits, el ahorro será mayor.

Su idea de dividir los caracteres en fragmentos de 4 bits probablemente no le ahorrará mucho, a menos que todos sus caracteres esperados estén en un rango extremadamente limitado (tal vez esté bien para palabras limitadas a US-ASCII mayúsculas, probablemente no con un corpus Unicode general) )

Si tiene un conjunto de caracteres disperso, entonces una HashMap<Character,Map<...>>podría ser su mejor implementación. Sí, cada entrada será mucho más grande, pero si no tiene muchas entradas, obtendrá una victoria general. (como nota al margen: siempre pensé que era divertido que el artículo de Wikipedia sobre Tries mostrara, tal vez todavía lo hace, un ejemplo basado en una estructura de datos hash, ignorando por completo las compensaciones espacio / tiempo de esa elección)

Finalmente, es posible que desee evitar un trie por completo. Si está viendo un corpus de palabras normales en un lenguaje humano (10,000 palabras en uso activo, con palabras de 4 a 8 caracteres de longitud), probablemente estará MUCHO mejor con un HashMap<String,List<String>, donde la clave es el prefijo completo.

si codifica las cadenas en UTF8, puede usar el trie de ramificación 256 estándar y seguir siendo compatible con Unicode

también debe tener en cuenta que solo 70 caracteres de los 128 caracteres ascii posibles (que todos codifican a 1 byte en UTF8) se encontrarán con mayor frecuencia que puede optimizar para eso (como incluir los dígrafos comunes en lugar de los caracteres de control no utilizados )