Предотвращение проблем с памятью при обработке больших объемов текста - PullRequest
8 голосов
/ 15 сентября 2009

Я написал программу, которая анализирует исходный код проекта и сообщает о различных проблемах и показателях на основе кода.

Для анализа исходного кода я загружаю файлы кода, которые существуют в структуре каталогов проекта, и анализирую код из памяти. Код проходит обширную обработку, прежде чем он передается другим методам для дальнейшего анализа.

Код передается нескольким классам при обработке.

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

Как лучше всего избежать проблем с памятью?

Я думаю о загрузке кода, выполнить первоначальную обработку файла, затем сериализовать результаты на диск, чтобы при повторном обращении к ним мне не приходилось проходить процесс манипулирования необработанным файлом. Снова код Имеет ли это смысл? Или сериализация / десериализация дороже, чем повторная обработка кода?

Я хочу сохранить разумный уровень производительности при решении этой проблемы. В большинстве случаев исходный код без проблем помещается в памяти, поэтому есть ли способ «пролистать» мою информацию, когда у меня мало памяти? Есть ли способ узнать, когда моему приложению не хватает памяти?

Обновление : Проблема не в том, что один файл заполняет память, его все файлы в памяти сразу заполняют память. Моя текущая идея состоит в том, чтобы вращать диск при обработке их

Ответы [ 4 ]

3 голосов
/ 15 сентября 2009

1,6 ГБ по-прежнему управляемы и не должны вызывать проблем с памятью. Неэффективные строковые операции могут сделать это.

Когда вы анализируете исходный код, вы, вероятно, разделяете его на определенные подстроки - токены или как вы их называете. Если ваши токены объединяют весь исходный код, это удваивает потребление памяти. В зависимости от сложности обработки, которую вы делаете, мультипликатор может быть даже больше. Мой первый шаг здесь будет состоять в том, чтобы поближе взглянуть на то, как вы используете свои строки, и найти способ их оптимизировать - т.е. отбросить origianl после первого прохода, сжать пробелы или использовать индексы (указатели) для исходных строк, а не фактические подстроки - здесь есть ряд методов, которые могут быть полезны.

Если бы ничего из этого не помогло, я бы прибегнул к их замене на диск

1 голос
/ 15 сентября 2009

Если проблема в том, что одна копия вашего кода заставляет вас заполнить доступную память, тогда есть как минимум два варианта.

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

Вам также следует проверить, правильно ли вы утилизируете предметы. Есть ли у вас проблемы с памятью из-за старых копий объектов, находящихся в памяти?

0 голосов
/ 15 сентября 2009

Сериализация / десериализация звучит как хорошая стратегия. Я сделал изрядное количество этого, и это очень быстро. На самом деле у меня есть приложение, которое создает объекты из БД, а затем сериализует их на жесткие диски моих веб-узлов. Прошло много времени с тех пор, как я тестировал его, но он сериализовался несколько сотен секунд и, возможно, более 1 тыс. Назад, когда я тестировал нагрузку.

Конечно, это будет зависеть от размера ваших файлов кода. Мои файлы были довольно маленькими.

0 голосов
/ 15 сентября 2009

Используйте WinDbg с SOS, чтобы увидеть, что удерживает ссылки на строки (или что вообще вызывает чрезмерное использование памяти).

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...