Гм... Согласен! Не хотелось бы в С спускаться...но, похоже придется.


Непонял...  На х32 ограничение 4гб. Или я чего не понял?

Там если комменты почитать, то есть и обратные результаты. Пока сам не потестиш с разными реализациями не примешь правильное решение.

Надо что-то с алгоритмом думать. Если программа начинает работать со свопом, то смысла тогда уже нет все держать в памяти, т.к. это равнозначно обычному чтению байтов из файла.

Это сообщение отредактировал(а) SABROG - 29.7.2008, 12:44

ОС тоже кушать хочет

К примеру...?

Думаю - ДА.
Это алгоритм унификации слов. Т.е. есть каталог  котором хранятся файлы словарей(простые .txt). Так вот при добавления нового файла, нужно проанализировать все словари на предмет повторения слов. Сами понимаете, итераций...ого-го  

Ты чего не понял  Фактически для пользовательской программы система предоставляет 2гб виртуального адресного пространства. Часть адресов уже занята системными модулями и их данными, часть является служебной, часть под стек и кучу. На практике ограничение составляет порядка 1.5 гб. 

Всегда есть два направления: память и быстродействие. В любом случае работа с данными находящимися в физической памяти(файл подкачки к которой не относится) будет всегда быстрее. Нужно найти золотую середину. 

Действительно ли у тебя присутствует наобходимость хранить все 6млн. объектов в памяти? 

для процесса - 2Гб

кстати можно использовать паттерн light weight
хранить не массив строк, а массив объектов
каждый объект хранит номер строки (или смещение) в файле
если объект не используется, то он хранит необходимый минимум данных, для того что-бы он мог считать себя из файла
если к объекту происходит обращение, то он считывает свои данные из памяти(так как знает откуда читать) прозрачно для клиента

Вообще это дурной подход к делу, так как нужно заботиться о масштабировании, завтра тебе понадобится обработать не 6 000 000 объектов, на несколько порядков больше, и ни в какую память они не влезут, что будешь делать? 

Добавлено через 1 минуту и 38 секунд

ну так это просто индексация, все читать не обязательно...

Согласен. Нет, памяти хватает. Но как-то медлено это все происходит... Я просто кимарю на раб. месте, пока день не закончится. В данный момент в словарях 5 746 337 слов, операция над ними занимает ~13 часов на P4 Core 2 Duo 3.2Ghz? 2Gb ram DDR2-Dual.
Может есть какие-то иные методы...?

винду можно с ключиком запустить и будет 3

Да БД однозначно.

Добавлено через 1 минуту и 38 секунд
Надо сделать ещё одну оговорку. БД может не подойти в случае, если исходный формат, в котором будут поступать данные, всегда будет txt и от тебя это не зависит. И в случае, если данные словари достаточно часто меняются. 

а на что время в основном тратится?

Абсолютно согласен. Исправлю.

В случае, если структура файла меняется редко или она просто дополняется новыми словами с конца, можно хранить не слова, а хеши. Ессно проиндексировать, но здесь простое соответветствие -- хеш+позиция_в_файле

я просто подумал, если происходят частые, случайные обращения к разным записям словаря (если одна запись словаря - одна запись БД), и частые их апдэйты, то не факт что будет быстро, хотя я не работал с БД...

Может есть смысл воспользоваться одной из баз данных ? В них уже реализованы алгоритмы поиска, сравнения, индексации, экономии памяти и т.д.

А вообще словари надо попросту специальным образом проиндексировать. Например создаешь файл индекса, где букве "А" соответствует стартовое смещение в файле каждого словаря и длинна участка. В итоге в память ты уже будешь загружать не все слова, а только на букву "А", далее сравниваешь сначала строки по размеру. Если длинна строк не идентична, то они уже не равны (правда не знаю, может функция сравнения строк уже так и делает.

Тогда ещё отсортировать надо 

Добавлено через 6 минут и 29 секунд


Всё-таки лучше действительно посчитать один раз хеши. Возьми какую-нибудь быструю хеш-функцию, например adler32, создай массив простых структур/классов, которые бы хранили хеш слова + позицию слова в файле, можно ещё длину слова. Если основная операция сравнение слов, то здесь ты многократно выигрываешь. 

Мало памяти, высокая производительность как раз в случае проверки дубликатов.