我在許多上下文中使用XSLT鍵。通常,使用的密鑰或多或少都是唯一的,而且非常罕見的重複實例。現在我定義了一個關鍵字,它有一些關鍵值的實例。準確地說:我正在處理一個具有@STEREOTYPE屬性的420.000條目的1.7 GigaByte文件。一些刻板印象發生達90.000次。不過,這些並不是我感興趣的。我想選擇的那些通常可能有10到20個實例。XSLT索引有許多相同的鍵的性能問題
的鍵定義是
<xsl:key
name="entityByStereotype"
match="/REPOSITORY_DUMP/ENTITY_LIST/ENTITY"
use="@STEREOTYPE"/>
索引的建築永遠持續,即我通常爲5或6小時後終止進程。
的替代密鑰的定義是
<xsl:key
name="entityByStereotype"
match="/REPOSITORY_DUMP/ENTITY_LIST/ENTITY"
use="concat(@STEREOTYPE, @OBJECT_ID)"/>
迫使實例關鍵字是唯一的,它的構建返回14秒之後。我的假設是排序算法對於同一個鍵的多個實例不能很好地工作,從而導致具有相同鍵的所有子集的O(n ** 2)複雜度。對於90.000個條目的子集,這是非常糟糕的。 :-(
但是,我不能使用備用索引定義,因爲我不知道事先實例的OBJECT_ID部分
任何想法非常感謝
撒克遜使用:?!9.1版.0.5
您可以預處理輸入文檔以排除不需要的重複項嗎?這可以通過例如使用快速SAX解析器。 – 2010-09-14 11:55:14
哪些是使ENTITY有趣的確切標準?你不能從這些標準中建立關鍵嗎? – 2010-09-14 12:07:03
準確的標準是尋找一個特定的STEREOTYPE。目前,沒有其他的標準可用。預處理輸入可能是一個選項。我可以將這個實體子集移動到XML樹中的不同位置。通過一定的努力,這可能會解決特定的問題。但是,知道索引速度如此之慢的真正原因是很好的。另外,我們處理的其他部分實際上可以從STEREOTYPE上的這個特定索引中受益。 – 2010-09-14 12:47:42