vc++調(diào)用jni

最終，當Lucene執(zhí)行查詢時，在初始設(shè)置后，真正的熱點通常是相當基本的代碼，該代碼對整數(shù)docID，術(shù)語頻率和位置的順序塊進行解碼，并將它們匹配（例如，對BooleanQuery并集或交集） ），則為每個匹配項計算得分，并在收集過程中保存具有競爭力的匹配項。 甚至顯然復(fù)雜的查詢（如FuzzyQuery或WildcardQuery FuzzyQuery經(jīng)過重寫過程，從而將其簡化為更簡單的形式（如BooleanQuery 。 Lucene的熱點非常簡單，以至于無法通過將它們移植到本地C ++（通過JNI）來對其進行優(yōu)化！

因此，我這樣做了，創(chuàng)建了lucene-c-boost github項目，其結(jié)果是令人興奮的：

任務(wù) QPS基礎(chǔ) 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倍 醫(yī)學(xué)術(shù)語 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倍 內(nèi)部NRQ 5.0 （1.4％） 38.7 （2.1％） 7.8倍

這些結(jié)果顯示在完整的，多領(lǐng)域的Wikipedia英語索引中，包含33.3 M個文檔。 除了令人驚訝的加速性能外，還很高興看到優(yōu)化的C ++版本的差異（StdDev列）通常較低，因為（大部分）熱點已被排除在等式之外。

該API易于使用，并且可與默認編解碼器一起使用，因此您無需嘗試重??新編制索引即可：代替IndexSearcher.search ，請調(diào)用NativeSearch.search 。 如果查詢可以優(yōu)化，它將被優(yōu)化； 否則，它將無縫地回IndexSearcher.search 。 它與Lucene完全分離，并與現(xiàn)有的Lucene 4.3.0 JAR一起使用，使用Java的反射API來獲取必要的位。

這都是非常新的代碼，我敢肯定有很多令人興奮的錯誤，但是（在經(jīng)過一些有趣的調(diào)試之后！）使用NativeSearch.search時，所有Lucene核心測試現(xiàn)在都可以通過。

這不是Lucene的C ++端口

此代碼絕對不是Lucene的常規(guī)C ++端口。 相反，它實現(xiàn)了一組非常狹窄的類，特別是常見的查詢類型。 這些實現(xiàn)不是通用的：它們硬編碼（專門化）特定代碼，刪除所有類似Scorer ， DocsEnum ， Collector ， DocValuesProducer等的抽象。

在何時應(yīng)用優(yōu)化存在一些主要限制：

• 到目前為止僅在Linux和Intel CPU上進行了測試
• 需要Lucene 4.3.x
• 必須將NativeMMapDirectory用作Directory實現(xiàn)，該實現(xiàn)將整個文件映射到RAM（避免基于Java的MMapDirectory必須執(zhí)行的分塊）
• 必須使用默認編解碼器
• 僅支持按分數(shù)排序
• 沒有一個優(yōu)化的實現(xiàn)使用advance ：首先，此代碼相當復(fù)雜，要移植到C ++會花費很多工作；其次，受益于先進的查詢通常已經(jīng)非常快了，因此我們不妨將它們留在Java中

BooleanQuery已優(yōu)化，但僅當所有子句都是針對同一字段的TermQuery時才進行優(yōu)化。

C ++不比Java快！

無論如何，不??一定如此：在有人大聲疾呼這些結(jié)果如何“證明” Java比C ++慢得多之前，請記住，這遠非“純粹的” C ++ vs Java測試。 至少有以下三個單獨的更改混合在一起：

• 算法更改。 例如， lucene-c-boost有時使用BooleanScorer ，其中Lucene使用BooleanScorer2 。 確實，我們需要修復(fù)Lucene來進行類似的算法更改（當它們更快時）。 特別是，在上述結(jié)果中包括Not子句以及IntNRQ所有OrXX查詢都將從算法更改中受益。
• 代碼專業(yè)化： lucene-c-boost將搜索作為強大的可怕外觀函數(shù)來實現(xiàn)，從而刪除了所有不錯的Lucene抽象。 盡管在Lucene中顯然需要抽象，但是不幸的是，它們增加了運行時的開銷，因此刪除這些抽象會帶來一些好處。
• C ++與Java

究竟是哪一部分收益多少尚不清楚。 實際上，我需要創(chuàng)建“匹配”的專用Java源代碼來進行更純粹的測試。

此代碼很危險！

具體地說，每當將本地C ++代碼嵌入Java時，Java開發(fā)人員都認為我們拋棄了C ++帶來的所有這些有趣的問題，總是存在風險。 例如，如果存在錯誤（可能是！），或者甚至是應(yīng)用程序濫用了無辜的API，例如在其他線程仍在使用IndexReader時意外關(guān)閉了IndexReader ，則該過程將遇到Segmentation Fault ，并且操作系統(tǒng)將破壞JVM。 。 可能還有內(nèi)存泄漏！ 而且，是的，C ++源代碼甚至使用goto語句 。

工作正在進行中…

這是一項正在進行的工作，仍然有許多想法需要探索。 例如，Lucene的4.3.x版的默認PostingsFormat店大端多頭，這意味著小端的Intel CPU必須做字節(jié)交換的每個帖子塊進行解碼時，這么一件事是嘗試一個PostingsFormat在搜索時CPU更好地優(yōu)化。 位置查詢，過濾器和嵌套BooleanQuery以及某些配置（例如，省略規(guī)范的字段）尚未進行優(yōu)化。 歡迎補丁！

盡管如此，初步的結(jié)果還是很有希望的，如果您愿意冒險冒險以換取大幅度的加速，請稍作調(diào)整并報告。

參考：來自我們的JCG合作伙伴 Michael Mc Candless的Changeing Bits博客通過JNI使用C ++進行了快速Lucene搜索 。

翻譯自: https://www.javacodegeeks.com/2013/06/screaming-fast-lucene-searches-using-c-via-jni.html

vc++調(diào)用jni

總結(jié)

以上是生活随笔為你收集整理的vc++调用jni_通过JNI使用C ++尖叫快速进行Lucene搜索的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。