C# 子集索引搜索的数据结构

我正在研究一种新的方法，并试图找出一种有效的算法来定位整个DOM的子集中的元素（例如，子选择器）。目前，我正在创建一个常见选择器的索引：构建DOM时的class、id和tag

基本数据结构如人们所期望的那样，是一个由

元素组成的树，其中包含
IEnumerable子元素
和
父元素
。使用
命令式
存储索引搜索整个域时，这很简单

我一直无法找到使用索引搜索元素子集的最有效方法。我使用术语“子集”来指链中的后续选择器将从中运行的起始集。以下是我想到的方法：

从整个DOM中检索子查询的匹配项，并消除不属于子集的匹配项。这需要遍历每个匹配项的父项，直到找到根（并将其删除）或找到子集的一个成员（并且它是子项，因此包括在内）
分别维护每个元素的索引
为每个元素维护一组父元素（通过消除遍历使#1变快）
为每个子查询重新生成整个索引
只需手动搜索，主选择器除外
每种可能技术的成本在很大程度上取决于所做的精确操作#1在大多数情况下可能相当不错，因为大多数情况下，当您进行子选择时，您的目标是特定的元素。所需的迭代次数是结果数*每个元素的平均深度

第二种方法是迄今为止最快的选择方法，但代价是存储需求随深度呈指数级增长，并且索引维护困难。我几乎已经消除了这个

第三种方法的内存占用情况相当糟糕（尽管比#2好得多）——这可能是合理的，但除了存储需求之外，添加和删除元素的成本和复杂性也会大大增加

第4个方法无论如何都需要遍历整个选择，因此它看起来毫无意义，因为大多数子查询只运行一次。只有当子方程被期望重复时，它才是有益的。（或者，我也可以在遍历子集时执行此操作，但有些选择器不需要搜索整个子域，例如ID和位置选择器）

第五种方法适用于有限的子集，但比第一种方法更适用于大部分DOM的子集

关于如何最好地实现这一点，有什么想法或其他想法吗？我可以将#1和#4混合在一起，根据搜索的子集的大小和DOM的大小，猜测哪一个更有效，但这是非常模糊的，我宁愿找到一些通用的解决方案。现在我只使用了#4（只有完整的DOM查询才使用索引），这很好，但如果您决定执行类似于
$（'body'）的操作，则这很糟糕。Find（'#id'）

免责声明：这是早期优化。我没有需要解决的瓶颈，但作为一个学术问题，我不能停止思考它

解决方案

下面是答案中提出的数据结构的实现。作为一本字典的替代品，它几乎可以完美地工作

interface IRangeSortedDictionary<TValue>: IDictionary<string, TValue>
{
    IEnumerable<string> GetRangeKeys(string subKey);
    IEnumerable<TValue> GetRange(string subKey);

}
public class RangeSortedDictionary<TValue> : IRangeSortedDictionary<TValue>
{
    protected SortedSet<string> Keys = new SortedSet<string>();
    protected Dictionary<string,TValue> Index = 
        new Dictionary<string,TValue>();
    public IEnumerable<string> GetRangeKeys(string subkey)
    {
        if (string.IsNullOrEmpty(subkey)) {
            yield break;
        }
        // create the next possible string match
        string lastKey = subkey.Substring(0,subkey.Length - 1) +
            Convert.ToChar(Convert.ToInt32(subkey[subkey.Length - 1]) + 1);

        foreach (var key in Keys.GetViewBetween(subkey, lastKey))
        {
            // GetViewBetween is inclusive, exclude the last key just in case
            // there's one with the next value
            if (key != lastKey)
            {
                yield return key;
            }
        }
    }

    public IEnumerable<TValue> GetRange(string subKey)
    {
        foreach (var key in GetRangeKeys(subKey))
        {
            yield return Index[key];
        }
    }
    // implement dictionary interface against internal collections
}

接口IRangeSortedDictionary:IDictionary
{
IEnumerable GetRangeKeys（字符串子键）；
IEnumerable GetRange（字符串子键）；
}
公共类RangeSortedDictionary:IRangeSortedDictionary
{
受保护的SortedSet键=新SortedSet（）；
受保护的词典索引=
新字典（）；
公共IEnumerable GetRangeKey（字符串子键）
{
if（string.IsNullOrEmpty（子键））{
屈服断裂；
}
//创建下一个可能的字符串匹配
string lastKey=subkey.Substring（0，subkey.Length-1）+
Convert.ToChar（Convert.ToInt32（subkey[subkey.Length-1]）+1）；
foreach（键中的var键。GetViewBetween（子键，lastKey））
{
//GetViewBetween是包含的，排除最后一个键以防万一
//有一个具有下一个值
if（key！=lastKey）
{
屈服返回键；
}
}
}
公共IEnumerable GetRange（字符串子键）
{
foreach（GetRangeKeys中的var键（子键））
{
收益率指数；
}
}
//针对内部集合实现字典接口
}

---

代码在这里：

如果您怀疑名称冲突不常见，那么它可能足够快，只需走到树上即可

但是，如果冲突很常见，那么使用在有序前缀搜索方面表现出色的数据结构（如树）可能会更快。前缀由不同的子集组成。然后，索引键将包括选择器和总路径

对于DOM：

<path>
  <to>
    <element id="someid" class="someclass" someattribute="1"/>
  </to>
</path>

您将拥有以下索引键：

<element>/path/to/element
#someid>/path/to/element
.someclass>/path/to/element
@someattribute>/path/to/element

/path/to/element
#someid>/path/to/element
.someclass>/path/to/element
@someattribute>/path/to/element

现在，如果根据前缀搜索这些键，则可以将查询限制为所需的任何子集：

<element>           ; finds all <element>, regardless of path
.someclass>         ; finds all .someclass, regardless of path
.someclass>/path    ; finds all .someclass that exist in the subset /path
.someclass>/path/to ; finds all .someclass that exist in the subset /path/to
#id>/body           ; finds all #id that exist in the subset /body

；查找所有，而不考虑路径
.someclass>；查找所有.someclass，而不考虑路径
.someclass>/path；查找子集/路径中存在的所有.someclass
.someclass>/path/to；查找子集/path/to中存在的所有.someclass
#id>/body；查找子集/正文中存在的所有#id

树可以在O（logn）中找到下限（搜索值的第一个元素>=），因为它是从那里开始排序的，所以只需迭代，直到找到一个不再匹配前缀的键为止。会很快的

.NET没有合适的树结构（它有SortedDictionary，但有unf）