Предотвращение Проблем памяти при обработке большого объема текста
Я думаю, что Вы делаете правильную вещь, пока ключи/значения для данного типа объекта часто изменяются.
, Если они довольно статичны, тогда просто делая таблицу объекта шире, имеет больше смысла.
Мы используем подобное (а скорее более сложный) подход с большой логикой вокруг ключей/значений, а также таблицами для типов значений, разрешенных для каждого ключа.
Это позволяет нам определять объекты как просто другой экземпляр ключа, и наша центральная таблица отображает произвольные ключевые типы на другие произвольные ключевые типы. Это может быстро связать Ваш мозг в узлах, но как только Вы записали и инкапсулировали логику для обработки всего этого, у Вас есть большая гибкость.
я могу записать больше деталей того, что мы делаем при необходимости.
4 ответа
1.6GB is still manageable and by itself should not cause memory problems. Inefficient string operations might do it.
As you parse the source code your probably split it apart into certain substrings - tokens or whatver you call them. If your tokens combined account for entire source code, that doubles memory consumption right there. Depending on the complexity of the processing you do the mutiplier can be even bigger. My first move here would be to have a closer look on how you use your strings and find a way to optimize it - i.e. discarding the origianl after the first pass, compress the whitespaces, or use indexes (pointers) to the original strings rather than actual substrings - there is a number of techniques which can be useful here.
If none of this would help than I would resort to swapping them to and fro the disk
If the problem is that a single copy of your code causing you to fill the memory available then there are atleast two options.
- serialize to disk
- compress files in memory. If you have a lot of CPU it can be faster to zip and unzip information in memory, instead of caching to disk.
You should also check if you are disposing of objects properly. Do you have memory problems due to old copies of objects being in memory?
Используйте WinDbg с SOS, чтобы узнать, что удерживается в строковых ссылках (или что когда-либо вызывает чрезмерное использование памяти).
Сериализация / десериализация звучит как хорошая стратегия. Я сделал изрядное количество этого, и это очень быстро. Фактически у меня есть приложение, которое создает экземпляры объектов из БД, а затем сериализует их на жесткие диски моих веб-узлов. Прошло некоторое время с тех пор, как я тестировал его, но он сериализовал несколько сотен в секунду и, возможно, более 1000 назад, когда я проводил нагрузочное тестирование.
Конечно, это будет зависеть от размера ваших файлов кода. Мои файлы были довольно маленькими.