Должен ли я загружать все в память при запуске приложения?

Question

Я использую VB.Net, и у меня есть набор данных, которые я должен довольно быстро отфильтровать. По сути, программа похожа на Google Sugest, но вместо выпадающего меню я использую список. Когда пользователь вводит слово, я сравниваю слово, используя LINQ, и фильтрую те, которые содержат ввод пользователя. Все данные представляют собой строки переменной длины (от 0 до 200 символов, большинство из которых имеют маркировку в 150 символов), и у меня есть 240 000+ этих строк, и все они хранятся в файле XML.

Мой коллега сказал мне, что загрузка всего этого в память (с помощью XML-сериализатора VB.Net плюс коллекции строк / объектов) нецелесообразна и замедлит время запуска программы. Я еще не закончил сборку программы, и у меня возникают мысли о продолжении этого пути.

Итак, мой вопрос: следует ли мне продолжить мой текущий подход к проблеме (которая заключается в загрузке всего в память при запуске) или есть лучший способ решения моей дилеммы?

Answer 1

Если вы хотите предотвратить время запуска и сохранить его в памяти, это не влияет на производительность, загрузите его асинхронно. Хотя загрузка 240.000+ строк из XML и сохранение их в памяти не самая лучшая идея. Возможно, база данных будет лучшим подходом. Или, по крайней мере, какой-нибудь формат, такой как JSON, который быстрее разбирать.

Answer 2

Возможно, вам лучше будет использовать двоичную сериализацию, а не сериализацию XML, чтобы сохранить данные, которые ваше приложение читает при запуске, особенно если вы в конечном итоге реализуете структуру данных, которая быстрее выполняется поиск, чем `StringCollection. Конечно, вы все равно сохраняете где-нибудь XML-версию данных.

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

Answer 3

Вопрос, кажется, подразумевает онлайн-приложение . Несколько предложений, если это так:

• Данные могут / должны быть zip . Я подозреваю, что это очень хорошо сжимается.
• Возможно, данные могут быть кэшированы в несколько сеансов , возможно, доставлены в виде html-контента с соответствующей датой истечения срока хранения. Это сохранит систематическую загрузку и может быть осуществимо, если данные не обновляются часто.
• Функция предложения может быть изначально отключена (т. Е. Показывать сообщение "загрузка ...", пока приложение инициализирует кэш, асинхронно ) , Таким образом, приложение будет быстро доступно при запуске, даже если функция подсказки может отставать примерно на 30 секунд.

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

Answer 4

Не может быть плохой идеей загрузить XML в память при запуске приложения. Но если вы пойдете по этому пути, я рассмотрю использование потока BackgroundWorker . Идея состояла бы в том, чтобы загрузить XML в память асинхронно, чтобы пользовательский интерфейс все еще реагировал на происходящее. Что касается пользователя, приложение не должно запускаться медленнее, и все же однажды сделанная функция, похожая на Google, должна стать значительно быстрее.

Я должен сказать, что даже в памяти это по своей сути неэффективная операция, поскольку у вас нет преимущества при использовании индекса при запросе файла XML таким способом. Это что-то, что в 10 раз быстрее в SQL с полнотекстовым поиском .

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

Answer 5

Вы говорите о загрузке примерно 36 МБ строк. Несмотря на то, что это совсем не страшно (хотя вы могли бы загрузить его быстрее, читая XML самостоятельно ... Я бы не стал использовать механизм сериализации, если бы беспокоился о производительности), это также нетривиальная величина. , Вы рассчитываете добавить пару секунд ко времени запуска, если предположить, что вы делаете это не асинхронно, как предполагает Мирча.

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

Answer 6

Зависит от нескольких вещей:

If 
((you know the strings will not hugely increase in number) && 
(you know the spec of the machines that will run your app) && 
(you are able to test that the load time is *good enough* on the above spec))
{
**don't bother changing approach.** 
}
else
{
**change approach.**
} 

Альтернативный подход - это, очевидно, асинхронная ленивая загрузка.