Как посчитать словарь текста?

Текст конечен. Реализацию буду писать на Golang. Можете уточнить ответ до да-да, нет-нет?

uvelichitel: Реализацию буду писать на Golang. То есть у меня в инструментарии еще будет ассоциативный массив.

Ну вот давайте подумаем, что проще: сделать в памяти дерево на 5 Мбайт, либо обработать гору текста размером 14 Гб ?
Я бы выбрал потоковое решение, и именно реализация дерева(ассоциативного массива) дает вам в этом выигрыш.

Кажется хэширование не бесплатно, разве что фильтр Блума подешевле. Но это все не overingeneering вы считаете? Можно оценить на каком размере текста и словаря это окупается? Ссылки на оценку будет достаточно для меня.

uvelichitel: "дешевле" только по использованию памяти и времени поиска в дереве. Хэш - сравнительно небольшое бинарное число (4-8 байт). Слова в юникоде будут иметь гораздо больший объём и сравниваться будут посимвольно. Т.е. чем больше длина слов и, чем больше вообще слов (больше высота дерева), тем больше будет выгода от хэширования.
Не знаком со спецификой golang, может на нём и нет разницы, но на настоящих языках программирования с числами работа происходит существенно быстрее, чем со строками.

maagames.ru: Вы меня не поняли. Хэш дорог в производстве, его же нужно считать. Памяти в условиях моей задачи достаточно.

uvelichitel: Я понял. Дороговизна хэш-функции зависит от того, что за хэш функция. Можно хоть CRC считать, хоть банально ксорить буквы (но не надо)...
Сортированный массив имеет смысл делать только если заранее известно количество разных слов (а это не известно). Так что строй дерево и не парься, тем более памяти полно.

maagames.ru: Идея с хэшем интересна. Подскажите легкую функцию для текста 10000 слов, словаря 500 слов, слова 10 юникод рун и я отмечу ответ решением.))))

uvelichitel: Я не знаю возможностей golang. Если разруливать коллизии (про несколько деревьев уже писали в первом ответе), то достаточно ксорить все символы строки. Если коллизии постараться избежать, то md5, но там много битовых операций. Если golang умеет в деление больших чисел, то можно остаток от деления на простое число считать. Ради словаря в 500 слов нет смысла заморачиваться и можно обычное дерево строить (8 сравнений строк в среднем потребуется). Даже ради 10000 слов особого смысла нет (всего 14 сравнений потребуется).

Верно. Язык дает мне Мапу в которой из коробки реализовано бинарное дерево с хэшированием. А что быстрее академически? В принципе же не трудно написать сортировку и сложение руками. И еще, в Go Мапа никак не упорядочена для циклического доступа и извлекать из нее по старшинству счетчика я не смогу. Поэтому мне нужно будет перелить в массив и все равно сортировать по счетчику. А какая Мапа в java- syntax или stdlib, hash func или memory layout, 'for range Map' упорядочено или случайно?

uvelichitel: т.е важно еще и результат отсортировать по старшинству?

uvelichitel: тогда лучше конечно лучше сразу использовать структуры в основе которых дерево.

Да