Ефективна реалізація Trie для рядків Unicode

Я шукав ефективну реалізацію String trie. Здебільшого я знайшов такий код:

Референційна реалізація на Java (за вікіпедією)

Мені не подобаються такі реалізації з двох причин:

1. Вони підтримують лише 256 символів ASCII. Мені потрібно висвітлювати такі речі, як кирилиця.
2. Вони надзвичайно малоефективні.

Кожен вузол містить масив з 256 посилань, що становить 4096 байт на 64-бітній машині в Java. Кожен з цих вузлів може мати до 256 підвузлів з 4096 байтами посилань кожен. Таким чином, повне Trie для кожного символьного рядка ASCII 2 вимагатиме трохи більше 1 Мб. Три символьні рядки? 256 Мб просто для масивів у вузлах. І так далі.

Звичайно, я не маю наміру мати в моєму Трі 16 мільйонів трьох рядків символів, тому багато місця просто витрачено. Більшість цих масивів є лише нульовими посиланнями, оскільки їх ємність значно перевищує фактичну кількість вставлених ключів. І якщо я додаю unicode, масиви стають ще більшими (char має 64k значення замість 256 у Java).

Чи є надія зробити ефективну трійку для струн? Я розглянув декілька вдосконалень щодо таких типів реалізацій:

• Замість використання масиву посилань я міг би використовувати масив примітивного цілого типу, який індексує масив посилань на вузли, розмір яких близький до кількості фактичних вузлів.
• Я міг би розбити рядки на 4 бітні частини, що дозволило б створити масиви вузлів розміром 16 ціною глибшого дерева.

Для чого ти використовуєш цю трійку? Яка загальна кількість слів, які ви плануєте дотримати, і яка обмеженість їх складових символів? І найголовніше, чи підходить трійка (проти простої карти префікса до списку слів)?

Ваша ідея проміжної таблиці та заміни покажчиків на індекси спрацює за умови, що у вас порівняно невеликий набір коротких слів та розріджений набір символів. В іншому випадку ви ризикуєте не вистачити місця у проміжному столі. І якщо ви не дивитеся на надзвичайно малий набір слів, ви дійсно не заощадите стільки місця: 2 байти за короткий та 4 байти для посилання на 32-бітній машині. Якщо ви працюєте на 64-бітному JVM, економія буде більше.

Ваша ідея про розбиття персонажів на 4-бітні шматки, ймовірно, не допоможе вам значно, якщо тільки всі ваші очікувані символи не будуть в надзвичайно обмеженому діапазоні (можливо, добре для слів, обмежених великими літерами US-ASCII, мабуть, загальним корпусом Unicode ).

Якщо у вас набір розріджених символів, то це HashMap<Character,Map<...>>може бути найкращою реалізацією. Так, кожен запис буде значно більшим, але якщо у вас не буде багато записів, ви отримаєте загальний виграш. (як бічна зауваження: я завжди вважав смішним, що стаття у Вікіпедії про Триес показала - можливо, і все-таки - приклад, заснований на хешированій структурі даних, повністю ігноруючи проміжок часу / часу цього вибору)

Нарешті, ви можете взагалі уникнути трійки. Якщо ви дивитесь на корпус звичайних слів людською мовою (10000 слів в активному використанні, зі словами 4-8 символів), вам, ймовірно, буде МНОГО краще з а HashMap<String,List<String>, де ключовим є весь префікс.

якщо ви кодуєте рядки в UTF8, ви можете використовувати стандартне триє розгалуження 256 і все ще бути сумісним з unicode

також слід зауважити, що лише 70 або більше символів з можливих 128 символів Ascii (які всі кодують до 1 байта в UTF8) будуть знайдені найбільш важко, ви можете оптимізувати для цього (наприклад, включіть загальні діаграми замість невикористаних символів керування )