hkhk366

@gwy15 谢谢回复，但是我把 HS_FLAG_LITERAL 改成了 0 或者其他值后，输出结果是下面，还是不对，头疼
Hyperscan 版本: 5.4.2 2024-10-06
模式 "test" 首次出现位置: 0
模式 "string" 首次出现位置: 0
模式 "example" 首次出现位置: 0
模式 "中文" 首次出现位置: 0

@kuanat 恕我直言，你这个和没逆向没有任何区别。
1.MFT 和 USN 这个所有人都知道，根本不需要逆向，直接跳过。
2.文件大小，修改时间这些信息当然不用逆向都知道必须存内存，否则根本无法这么快。能优化排序的方法就那么几个，和没说一样。
3.唯一有逆向价值的就是，everything 作者自述它自己实现了高度优化的正则引擎，而这个你又根本什么都没分析出来。
4.pcre 需要外部安装，这根本不需要逆向，Levenshtein 内存消耗太大，everything 搜索的时候根本内存变化很小，根本没必要逆向就知道不使用的外部 PCRE 或者 RE2 。

恕我直言，你这个逆向和没逆向没有任何区别，都仅仅是泛泛而谈，不停的在表示 everything 没壳没混淆很好分析，而我表示大部分算法级别从汇编还原是非常难的。

我可没有泛泛而谈，每一个实现方法我都说出了具体算法名字和我自己实现后大约什么性能，我是真的做过测试。既然这样你认为逆向分析 everything 这么简单，那你就分析一下作者这个高度优化正则引擎具体是怎么做的，把具体分析的地址和对应汇编贴出来还有你分析过的 everything 版本都发出来，我看得懂汇编，我也懂动态和静态逆向分析，请不要泛泛而谈。Talk is cheap. Show me the code.

@ntedshen 感谢手动测试，类似的测试我试过，你看你的索引文件已经超过 120MB ，显然还是 everything 的方式更小，而且你这样做是不支持 everything 正则表达式的，everything 正则表达式和普通搜索是几乎一样速度，而且你只获取了前 500 个，这个不能说明问题，如果不优化会出现深分页问题。还有就是这种方法我也尝试过，如果大量插入数据，无法在 1 秒内对 100 万文件实现插入。

@iseki
@soy
非常感谢两位，这个作者的回复收益良多。我自己测试过，多线程正则的确能将速度压倒 6 到 10 毫秒，对方是经过特殊优化的，我这个只是通用的。
我想问一下“至于搜索结果快速排序，everything 额外维护了一个快速排序索引，所有文件已经按日期/大小等索引预排序了”这个具体如何做？

根据我的理解，比如按文件大小排序，文件大小是排序 key ，然后每一项至少还得保存一个指针指向自己的主结构吧，然后遍历这个提前排好的数组或者链表，然后一个一个走正则。当文件变动的时候这个数组或者链表也要调整。

@kuituosi 我想了解一下，如何剪枝，怎么剪枝这很关键。剪枝一般用于树，全文索引可不是树，你怎么剪枝呢？请给一个具体例子

@BeautifulSoap 感谢，你是唯一愿意自己动手测试一下，go 语言我也会，我一开始整个项目就是 go 写的，后来发现性能完全不能满足我的要求，所以我换成了比 go 更快的编译型语言写。正如你自己所说，你是用的随机字符串，并不是真实数据，所以就会有很大的偏差，我当然自己也试过，我不是那种不动手就上来。实验结果就是真实数据单线程查询超过了 40 毫秒，因为我搜的是包含"a"，100 万真实数据有大量是包含“a”的，而且有个最关键因素，你搜的[]string 吧，真实数据每一个记录不可能 string ，因为至少还有文件大小，修改时间等等，一带上这些立刻性能严重下降，为什么会突然下降呢？这个问题留给你

@matrix1010 感谢回复，但是用 sqlite 即使关闭各种配置以增加吞吐量也是无法在 1 秒内实现 100 万数据的插入，包括文件名，文件路径，文件大小，修改时间，访问时间，创建时间。我已经说了，文件名不能用普通分词，我是按照每个字母当分词，我自己实现了倒排索引一个版本，再用 sqlite 都不行，sqlite 比我自己实现的还慢。论坛上有其他人套壳全文搜索引擎，最后同样的文件 everything 120MB 以内，全文搜索引擎内存超过 250MB ，而且结果没按照文件大小排序，这些我都在 1 楼帖子说明过。

@kuanat 你好，谢谢你的回复，但是你完全没有仔细阅读 1 楼的内容，我从来没有讨论文件内容索引的问题，我从来没提文件 IO 的事情。我一直讨论的是文件名，文件路径，文件大小，修改时间这些快速索引，搜索，排序的问题。

至于 x64 逆向我会，但是你能从从汇编反向推出来核心索引算法吗？除非花费大量的时间，否则根本不可能，你顶多下个断点，知道什么时候触发一下。

@tool2d 感谢回帖，我也想过 bloom filter ，但是我自己测试是这样的，上面也有提到，我的硬盘中有 100 万文件，其中几十万（具体 90 万）文件都包含"a"，我不知道他是如何在 5 毫秒（ everything 单个字符搜索 5 毫秒，二哥字符 15 毫秒）内完成的，现在 bloom filter 对这个案例过滤不了多少，并且用 priority_queue 也无法保证在 5 毫秒内完成 90 万文件搜索+排序。所以最大的问题是，everything 能再 5 毫秒内完成 90 万文件的操作，并且整个过程中好像还没有并行计算，我观察 CPU 都多核没变化。如果按照分库分表并行的话，必然 CPU 会有不少波动，我上面说的并行方法其实就用的分库分表，不能符合预期。还有什么其他的方法愿意分享吗？多谢