@bronyakaka 禁止造谣，闭源怎么了，其他类似能达到这个效率的软件哪个不闭源，想白嫖别人核心算法？还木马，笑话，看看 https://habo.qq.com/file/showdetail?pk=ADEGZF1lB2UIMVs6U2oHYA%3D%3D

@humbass 上来动不动就最烦，我可以翻过来说，我最烦你这种不认真审题的，我哪里写我必须开源的，github 使用条例哪一条说必须完全开源才能创建 repo ，没人逼你用，你既不是投资人也不是赞助者，你的意见压根不重要，不要像个领导一样发号施令。

@NoOneNoBody 我也没逼着你用啊，你说的一切无非是加个功能而已，everything 做了 20 年，都没满足你的全部需求，让我上来满足一切？

@NoOneNoBody everything 开放的 sdk 功能很有限，这是理所当然，如果开放的功能超过其本身就会功高盖主。对于那些只需要短暂用一下的项目，sdk 是可行的，因为这种项目出发点就仅仅是能用而已。但是我的出发点是做一个大系统，我认为为了支持更多的功能，自研算法是唯一出路。我喜欢研究底层原理，不管做什么，我喜欢了解底层原理。在研制核心搜索算法的过程中我也提高了很多，这些技术积累将用于我其他的工作上，我认为非常有益。

至于你说的这些 everything sdk 无法满足的这些，因为我算法是自研的，我全都可以做到，无非是花时间的问题了，如果一开始用了受限的 sdk 再去想加一些功能甚至比自研还要麻烦。

@NoOneNoBody 你说的这些问题我当然都研究过，他自己的 SDK 功能很不全，和他自己的搜索差很多。而且只有自己写出来核心算法才能真的学到东西，成天调 SDK 就只能永远只做个一个调包侠。

@moioooo 没关系，目前是 demo 版本主要研究的是搜索核心算法的性能。其他这些问题我会后续解决。因为只有先解决了文件名搜索下一步才能解决文件内容搜索。

顺便说一句，如果不想用 hosts ，也可以采用 https://github.com/FilePulseSoft/FilePulse 里面提到的“方案一：极简启动”，如果只希望在本地运行的话，可以直接输入 https://127.0.0.1 ，这样就不需要改 hosts 了。

我做这个工具的初衷是由于我需要远程对机器上的文件进行搜索，下载等操作，所以我才选用的 http2/http3 ，而 everything 的 http 服务是 http1.0 ，这个实在太老了，无法支持未来我的远程办公，远程协作，远程差异化存储等操作。所以我才下定决心做一个自己的。

@moioooo https://github.com/FilePulseSoft/FilePulse 在未来计划有提到，这个是第一步，未来会支持毫秒级文件内容搜索，将会成为一个既可以搜索文件名又可以搜索内容的实时搜索系统。

@cat9life 早就有详细对比在 github ，主要优势未来计划都在里面，v2ex 没法写这么全，内容越长 V2EX 扣费越多

https://github.com/FilePulseSoft/FilePulse

@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 会有不少波动，我上面说的并行方法其实就用的分库分表，不能符合预期。还有什么其他的方法愿意分享吗？多谢