KDE Kate文本编辑器–搜索文件和多线程

多年来，Kate在文件插件中进行了非常漂亮的搜索，它允许进行多文件搜索和替换。

但是，尽管自从第一个版本就已经非常有用，并且在最近几年中进行了很多改进，但到目前为止，它并不是最快的文件搜索。老实说：例如，Visual Studio Code速度很快，但我们速度很慢，那很糟糕：= P

对于21.04版本，KåreSärs（该插件的原始作者和维护者），Waqar Ahmed和我尝试​​纠正此问题。

实际的搜索已经有一些后台线程，但是仍然非常尴尬地直接填充到窗口小部件中。

Kåre在这里将其移植到适当的模型视图抽象中，这是实际计划的基础：不仅仅是一个搜索线程。

之后，Waqar在此处进行了更多微调，以为我们仍然使用一个后台线程进行完整搜索，这已经产生了大大提高的搜索性能。

在我2021年1月的摘要帖子中（太糟糕了，现在仍然是1月＆amp; mldr），我已经提到了不错的改进，结果的视觉表示也得到了很好的改观。

然后，Kåre做了下一步：使用带有一些QRunnable对象的QThreadPool允许多个后台搜索线程。 有趣的是，对于他的实验，只有两个线程产生了实实在在的好处，更多的线程则相反。 鉴于我有一台具有很多真实内核（16）和快速SSD的机器，因此我尝试对此进行更多试验。 我认为两个线程不会完全饱和内核或SSD。 这确实导致了第三步：尝试优化多线程并扩展2个线程。 首先，我只是在更快的计算机上尝试了当前的实现，是的，即使有16或32个线程，实际上2个线程还是差不多了，但是速度只有一点点。 一个想法是：在我们最初的方法中，我们只是将要搜索的文件分成了X个块。我认为这可能不是很好的平衡。

因此，我只是添加了一个简单的工作清单，这些工作清单是单个工人从中撤出的工作，没有任何初始静态拆分。

实际上，这本来应该是第一步，但是，嘿，总是有些猜测，因为谁不知道具体问题是什么，他就不知道解决方案。

作为分析数据集，我使用了linux.git克隆并在其中搜索“ Linus”，是的，非常有创意； =）

确实有2个线程需要9秒钟，而16个线程则需要8秒钟，正如我所说的那样。

让我们看一下理想线程数为16的运行的性能配置文件。

QMimeData可见，大约15％=>不好，只是整理二进制文件，而不是您要花那么多时间的事情

QRegularExpression是写时复制的隐式共享对象。将表达式从主线程传递到可运行对象，它将不会被复制，但这意味着，在大多数操作（例如match）上，它将进行内部锁定，例如match要优化实例之间仍然共享的表达式。

SearchDiskFiles :: SearchDiskFiles（SearchDiskFilesWorkList＆amp; worklist，const QRegularExpression＆amp; regexp，const bool includeBinaryFiles）：m_worklist（worklist），m_regExp（regexp。pattern（），regexp。patternOptions（））//我们想杀死共享，否则我们死定了！ ，m_includeBinaryFiles（includeBinaryFiles）

此操作和删除QMimeData查找（如果我们在匹配过程中从文件中读取二进制废话，则替换为一些琐碎的启发式搜索）可将搜索的运行时间缩短至约0.6秒。

在下面的此改进版本的性能概要中，即使比将大多数其他部分都更容易看到将排队的信号发送到主线程所涉及的锁定。

像kate.git克隆中的东西之类的较小搜索现在或多或少是瞬时的，例如约0.1秒。

可以肯定的是，正如个人资料所示，还有更多可以调整的内容，但总的来说，我认为当前状态非常好。我们现在可以与其他现代编辑器相提并论了，它在处理多文件搜索方面再次变得明智。

我们有很多想法，但只有少量的奴才（我是指有价值的贡献者）才能实现它们：）