Question

我正在使用VB.Net，我有一组数据，我必须能够很快过滤掉。基本上，该程序就像谷歌sugest，但我没有使用下拉菜单，而是使用列表框。当用户输入单词时，我使用LINQ比较单词并过滤包含用户输入的单词。数据都是可变长度的字符串（从0到200个字符，大多数在150个字符标记处），我有240,000+这个字符串和计数 - 都存储在XML文件中。

我的一位同事告诉我，将所有内容加载到内存中（使用VB.Net的XML序列化程序加上字符串/对象的集合）是不切实际的，并且会减慢程序的“启动”时间。我还没有完成程序的构建，我想继续这条路。

所以，我的问题是：我是否应该继续目前处理问题的方法（在启动时将所有内容加载到内存中），还是有更好的方法来解决我的困境？

Answer 1

如果要防止启动时间并将其保留在内存中不是性能问题，请以异步方式加载它。虽然从XML加载240,000个字符串并将其保存在内存中并不是最好的主意。数据库可能是更好的方法。或者至少有一些像JSON这样的解析速度更快的格式。

Answer 2

取决于许多事情：

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.**
}

替代方法显然是某种异步延迟加载。

Answer 3

你在谈论加载大约36MB的字符串。虽然这不是一个令人生畏的数量（虽然你可以加载它自己更快地读取XML ...如果我担心性能，我不会使用序列化引擎），这也是一个非常重要的数额。假设你没有像Mircea所暗示的那样异步地进行，那么你的启动时间会增加几秒钟。

如果您是异步执行此操作，则必须确保在加载之后才会发生任何依赖于数据的UI进程。这可能是一件难以确保的事情。

Answer 4

在应用启动时将XML加载到内存中可能不是一个坏主意。但是如果你走这条路，我会考虑使用BackgroundWorker线程。我们的想法是将XML异步加载到内存中，因此UI仍在响应，因为这种情况正在发生。就用户而言，应用程序似乎不应该开始变慢，但一旦完成，Google建议式功能应该明显加快。

我必须说，即使在内存中，这也是一种本质上效率低下的操作，因为在以这种方式查询XML文件时没有使用索引的优势。使用full-text searching的SQL速度要快10倍。

当然，XML具有自包含且不需要额外组件的优点。这使得它成为查询少量数据的小型桌面应用程序的理想选择。否则我会考虑使用数据库来获得更好的性能。

Answer 5

这个问题似乎意味着在线申请。如果是这样的话，可以提出一些建议：

数据可以/应该压缩。我怀疑它压缩得非常好。
也许数据可以在多个会话中缓存，可能会以适当的到期缓存日期作为html内容提供。这样可以节省系统负载，如果数据不经常更新，则可行。
最初可以禁用建议功能（即在应用初始化缓存时显示“loading ...”消息，异步）。以这种方式，应用程序可以在启动时快速获得，即使建议功能可能滞后最多30秒左右。

编辑：无论数据如何下载和缓存，我都认为Mircea Grelus认为这个大小的xml文件不能替代数据库。

Answer 6

使用二进制序列化而不是XML序列化来保持应用程序在启动时读取的数据可能会更好，特别是如果最终实现的搜索速度比`StringCollection更快的数据结构。当然，你仍然会在某处维护数据的XML版本。

并且无论如何，使用BackgroundWorker异步加载数据，如果这会让您的应用程序感觉更具响应性。

应用程序启动时我应该在内存中加载所有内容

6 个答案: