Какова правильная стратегия хранения большого количества текстовых данных в памяти?System.Runtime.Caching или пользовательские классы?

Question

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

Проблема: у меня есть программа WPF, которая выполняет различие между сотнями INI-файлов. Для повышения производительности я хотел бы сохранить в памяти несколько сотен базовых файлов, с которыми сталкиваются другие файлы. Я обнаружил, что использование пользовательских классов для хранения этих данных приводит к остановке моего графического интерфейса после загрузки 10-15 файлов с примерно 4000 строками данных в каждом.

Я рассматриваю несколько стратегий улучшения производительности:

• Не храните в памяти более нескольких файлов одновременно и забудьте о том, что, как я надеялся, улучшило бы синтаксический анализ, сохранив их в памяти
• Поэкспериментируйте с запуском всех данных базового файла в потоке BackgroundWorker. Я не делаю никакой работы с этими файлами в потоке графического интерфейса, но, возможно, все эти хранимые данные как-то влияют на это. Я предполагаю здесь.
• Эксперимент с System.Runtime.Caching классом.

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

Answer 1

Для этого следует использовать MemoryCache.

Он работает почти так же, как класс ASP.Net Cache, и позволяет вам установить, когда он должен очиститься, который должен быть очищенвверх и т. д.

Также позволяет перезагрузить элементы на основе зависимостей или по истечении определенного времени.Имеет обратные вызовы при удалении.

Очень завершено.

Answer 2

Предполагая, что 100 строк текста 15 *4000* 100 - это всего 6 МБ, что является обычным объемом памяти на современном ПК. Если ваш GUI останавливается, то для меня это свидетельствует о том, что виртуальная память выгружается на диск. Это не имеет смысла только для 6 МБ, поэтому я бы выяснил, сколько это действительно занимает и почему. Возможно, будет какая-то тривиальная ошибка, которую будет легче исправить, чем переосмыслить всю стратегию. Другая возможность состоит в том, что это не имеет никакого отношения к потреблению памяти, а скорее к проблеме алгоритма.

Answer 3

Если ваше приложение начинает зависать, это больше похоже на интенсивный процесс в вашем GUI-процессе, который потребляет слишком много ресурсов либо CPU / Memory в вашем потоке GUI, поэтому поток GUI не может перерисовать ваш UI вовремя.

Лучший способ решить эту проблему - создать отдельный поток для выполнения операции diff, как вы упоминали в своем посте, вы можете использовать backgroundworker, или вы можете использовать threadpool, чтобы создать столько потоков, сколько вы можете сделать.разн.

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