pssre

你好： 由于我平时不常查看邮件，因此如果你能用QQ的话，欢迎加入QQ群：948127686 FastSearch是一个未完成的项目，还处于初级阶段，目标是达到Everything的程度，但是在开发过程中发现要达到它的高度很困难， 主要技术难点是：扫描出磁盘中的所有文件后要能快速的索引和排序，并且不能占用过多的内存，这方面我没有找到核心的算法。 如果想要快速地扫描出磁盘中的所有文件，经过研究表明读取USN信息是最快的方法，FastSearch的思路是： 1、打开所有磁盘分区； 2、读取每个分区的USN文件信息放入字典中； 3、从字典中查询指定的文件。 因此你只需要关注： 和 在实现的时候，采用了IO完成端口或者多线程读取每个分区的所有文件，实践表明异步IO速度更快。 IO完成端口(iocp.h)的原理请参考《Windows核心编程》（美）Jeffrey Richter。 我对你的建议是增加sorteddictionary.h排序字典，可以参考微软的.NET Frameworks源码：SortedDictionary。 目前在所有字典算法中.NET Frameworks的Dictionary是非常好的，因此你会发现在不考虑排序的情况下FastSearch加载和搜索速度是最快的。 下面的排序思路可供你参考： 1、扫描出所有分区中的文件放在各个分区字典中； 2、查找数据时，将找到的文件放在SortedDictionary中； 3、将SortedDictionary中的数据显示在界面上，在显示的时候采用虚拟加载，即拖动滚动条的时候动态显示指定部分。 采用SortedDictionary，会产生性能损失，但对于查找数据的话，因为进行了过滤，性能损失不大。 这个思路的缺点是： 1、由于没有索引，每次查找数据都会扫描整个字典(这类似于数据库全表扫描，实际上你会发现多线程扫描字典速度非常快，因为其在内存中进行的)； 2、如果找到的数据很多(例如:*.txt)，会占用大量的内存，为了避免这种情形，搜索的时候应该记录字典搜索位置，当移动滚动条的时候再从字典中查找一定数量的数据（这类似数据库游标）。 显然，Everything不是这样处理的，其作者对数据库的索引和排序有深入的研究，由于我对这块没有涉猎，因此没有更好的思路供你参考。 但我的总体设计思路是：将所有文件扫描到字典中，把字典当成内存数据库，化繁为简。 但是要达到Everything一模一样的程度，要下很多功夫。 最后，我写的代码已经是非常简洁了，为了便于阅读源码，你在跟踪调试的时候，我建议你先用多线程的方式扫描文件信息，不要用IO完成端口，因为其难于跟踪，如下： filejournal.cpp...

很好的方式。为了性能，也可以考虑在listview控件显示文件的时候，根据文件号遍历出路径并显示出来。目前我们主要面临的问题还有一个是排序，例如根据文件名、文件路径、创建日期、修改日期、文件大小等排序。我的计算机上大约有300多万文件，如何对其按照不同维度进行快速排序并显示（最好能达到everything的速度），我想采用多线程归并排序或是选项之一，具体请你研究一下。另外，map的效率是否高于我改写的微软dictionary，如果你有时间的话请测试一下，我没有进行对比测试。在开发过程中可以参考：https://sourceforge.net/projects/swiftsearch/ 只是其代码写得实在太乱，阅读起来很不友好。 发自我的iPhone ------------------ 原始邮件 ------------------ 发件人: Jingwei Tu

补充：监控文件的增删改，开启一个线程，调用相应的API（可以找到示例），只需要以文件名为key放入字典中即可，如果有必要可以将字典进行压缩持久化到磁盘中。监控文件变化考虑的主要因素是删除或移动大量文件时带来的性能影响，监控不一定是非常准确的，有时候可能会重新扫描磁盘分区进行修正。最精确的监控是驱动级的，例如杀毒软件对文件的监控，如果你有耐心和精力可以考虑。 发自我的iPhone ------------------ 原始邮件 ------------------ 发件人: Jingwei Tu

究竟哪一种排序适合，可能需要根据不同场景进行优化选择，考虑多线程归并排序是基于everything的猜想。你在使用过程中开启everything的debug模式，会发现其排序采用了多线程。everything的大体过程是扫描文件、创建索引、进行排序、监控变化。我们不一定要按照他的设计思路做，就像我们把文件扫描进字典一样。期待你的好消息！ 发自我的iPhone ------------------ 原始邮件 ------------------ 发件人: Jingwei Tu