个人怎么做课程网站,海宁市规划建设局网站,广州网站建设seo,wordpress 在线编辑vc调用jni最终#xff0c;当Lucene执行查询时#xff0c;在初始设置后#xff0c;真正的热点通常是相当基本的代码#xff0c;该代码对整数docID#xff0c;术语频率和位置的顺序块进行解码#xff0c;并将它们匹配#xff08;例如#xff0c;对BooleanQuery并集或交集… vc调用jni 最终当Lucene执行查询时在初始设置后真正的热点通常是相当基本的代码该代码对整数docID术语频率和位置的顺序块进行解码并将它们匹配例如对BooleanQuery并集或交集 则为每个匹配项计算得分并在收集过程中保存具有竞争力的匹配项。 甚至显然复杂的查询如FuzzyQuery或WildcardQuery FuzzyQuery经过重写过程从而将其简化为更简单的形式如BooleanQuery 。 Lucene的热点非常简单以至于无法通过将它们移植到本地C 通过JNI来对其进行优化 因此我这样做了创建了lucene-c-boost github项目其结果是令人兴奋的 任务 QPS基础 StdDev基地 QPS选择 选择标准 变化百分比 高低 469.2 0.9 316.0 0.7 0.7 X 模糊1 63.0 3.3 62.9 2.0 1.0 X 模糊2 25.8 3.1 37.9 2.3 1.5倍 和高级 50.4 0.7 110.0 0.9 2.2倍 或高低 46.8 5.6 106.3 1.3 2.3 X 低期 298.6 1.8 691.4 3.4 2.3 X 或HighNotMed 34.0 5.3 89.2 1.3 2.6倍 或高不高 5.0 5.7 14.2 0.8 2.8倍 通配符 17.2 1.2 51.1 9.5 3.0 X 高高 21.9 1.0 69.0 1.0 3.5 X 或高级 18.7 5.7 59.6 1.1 3.2倍 或高高 6.7 5.7 21.5 0.9 3.2倍 或高低 15.7 5.9 50.8 1.2 3.2倍 医学术语 69.8 4.2 243.0 2.2 3.5 X 高或低 13.3 5.7 46.7 1.4 3.5 X 还是不高 26.7 5.8 115.8 2.8 4.3 X 高端 22.4 4.2 109.2 1.4 4.9倍 前缀3 10.1 1.1 55.5 3.7 5.5 X 高低 62.9 5.5 351.7 9.3 5.6倍 内部NRQ 5.0 1.4 38.7 2.1 7.8倍 这些结果显示在完整的多领域的Wikipedia英语索引中包含33.3 M个文档。 除了令人惊讶的加速性能外还很高兴看到优化的C 版本的差异StdDev列通常较低因为大部分热点已被排除在等式之外。 该API易于使用并且可与默认编解码器一起使用因此您无需尝试重新编制索引即可代替IndexSearcher.search 请调用NativeSearch.search 。 如果查询可以优化它将被优化 否则它将无缝地回IndexSearcher.search 。 它与Lucene完全分离并与现有的Lucene 4.3.0 JAR一起使用使用Java的反射API来获取必要的位。 这都是非常新的代码我敢肯定有很多令人兴奋的错误但是在经过一些有趣的调试之后使用NativeSearch.search时所有Lucene核心测试现在都可以通过。 这不是Lucene的C 端口 此代码绝对不是Lucene的常规C 端口。 相反它实现了一组非常狭窄的类特别是常见的查询类型。 这些实现不是通用的它们硬编码专门化特定代码删除所有类似Scorer DocsEnum Collector DocValuesProducer等的抽象。 在何时应用优化存在一些主要限制 到目前为止仅在Linux和Intel CPU上进行了测试 需要Lucene 4.3.x 必须将NativeMMapDirectory用作Directory实现该实现将整个文件映射到RAM避免基于Java的MMapDirectory必须执行的分块 必须使用默认编解码器 仅支持按分数排序 没有一个优化的实现使用advance 首先此代码相当复杂要移植到C 会花费很多工作其次受益于先进的查询通常已经非常快了因此我们不妨将它们留在Java中 BooleanQuery已优化但仅当所有子句都是针对同一字段的TermQuery时才进行优化。 C 不比Java快 无论如何不一定如此在有人大声疾呼这些结果如何“证明” Java比C 慢得多之前请记住这远非“纯粹的” C vs Java测试。 至少有以下三个单独的更改混合在一起 算法更改。 例如 lucene-c-boost有时使用BooleanScorer 其中Lucene使用BooleanScorer2 。 确实我们需要修复Lucene来进行类似的算法更改当它们更快时。 特别是在上述结果中包括Not子句以及IntNRQ所有OrXX查询都将从算法更改中受益。 代码专业化 lucene-c-boost将搜索作为强大的可怕外观函数来实现从而删除了所有不错的Lucene抽象。 尽管在Lucene中显然需要抽象但是不幸的是它们增加了运行时的开销因此删除这些抽象会带来一些好处。 C 与Java 究竟是哪一部分收益多少尚不清楚。 实际上我需要创建“匹配”的专用Java源代码来进行更纯粹的测试。 此代码很危险 具体地说每当将本地C 代码嵌入Java时Java开发人员都认为我们抛弃了C 带来的所有这些有趣的问题总是存在风险。 例如如果存在错误可能是或者甚至是应用程序滥用了无辜的API例如在其他线程仍在使用IndexReader时意外关闭了IndexReader 则该过程将遇到Segmentation Fault 并且操作系统将破坏JVM。 。 可能还有内存泄漏 而且是的C 源代码甚至使用goto语句 。 工作正在进行中… 这是一项正在进行的工作仍然有许多想法需要探索。 例如Lucene的4.3.x版的默认PostingsFormat店大端多头这意味着小端的Intel CPU必须做字节交换的每个帖子块进行解码时这么一件事是尝试一个PostingsFormat在搜索时CPU更好地优化。 位置查询过滤器和嵌套BooleanQuery以及某些配置例如省略规范的字段尚未进行优化。 欢迎补丁 尽管如此初步的结果还是很有希望的如果您愿意冒险冒险以换取大幅度的加速请稍作调整并报告。 参考来自我们的JCG合作伙伴 Michael Mc Candless的Changeing Bits博客通过JNI使用C 进行了快速Lucene搜索 。 翻译自: https://www.javacodegeeks.com/2013/06/screaming-fast-lucene-searches-using-c-via-jni.htmlvc调用jni
