不要问我是怎么到那儿的，但我一直在玩弄一些掩码、循环展开等。无论如何，出于兴趣，我在考虑如何实现一个 indexof 方法，长话短说，所有除了屏蔽等，这个天真的实现:

public static unsafe int IndexOf16(string s, int startIndex, char c) {
            if (startIndex < 0 || startIndex >= s.Length) throw new ArgumentOutOfRangeException("startIndex");
            fixed (char* cs = s) {
                for (int i = startIndex; i < s.Length; i++) {
                    if ((cs[i]) == c) return i;
                }
                return -1;
            }
        }

比 string.IndexOf(char) 快。我写了一些简单的测试，它似乎与输出完全匹配。 我的机器的一些样本输出数字(当然会有所不同，但趋势很明显):

short haystack 500k runs
1741 ms for IndexOf16
2737 ms for IndexOf32
2963 ms for IndexOf64
2337 ms for string.IndexOf <-- buildin

longer haystack:
2888 ms for IndexOf16
3028 ms for IndexOf32
2816 ms for IndexOf64
3353 ms for string.IndexOf <-- buildin

IndexOfChar 被标记为 extern，所以你不能反射它。但是我认为这应该是( native )实现: http://www.koders.com/cpp/fidAB4768BA4DF45482A7A2AA6F39DE9C272B25B8FE.aspx?s=IndexOfChar#L1000

他们似乎使用了相同的幼稚实现。

我想到的问题:

1) 我在我的实现中是否遗漏了一些解释为什么它更快的东西？我只能想到扩展字符支持，但他们的实现表明他们也没有为此做任何特别的事情。

2) 我假设许多低级方法最终将在手工汇编器中实现，但事实似乎并非如此。如果是这样，为什么要在 native 实现它，而不是像我的示例实现那样仅在 C# 中实现？

(在这里完成测试(我觉得这里贴太长了):http://paste2.org/p/1606018 )

(不，这不是过早的优化，它不是我正在搞的项目):-)

更新:感谢 Oliver 关于 nullcheck 和 Count 参数的提示。我已将这些添加到我的 IndexOf16Implementation 中，如下所示:

public static unsafe int IndexOf16(string s, int startIndex, char c, int count = -1) {
    if (s == null) throw new ArgumentNullException("s");
    if (startIndex < 0 || startIndex >= s.Length) throw new ArgumentOutOfRangeException("startIndex");
    if (count == -1) count = s.Length - startIndex;
    if (count < 0 || count > s.Length - startIndex) throw new ArgumentOutOfRangeException("count");

    int endIndex = startIndex + count;
    fixed (char* cs = s) {
        for (int i = startIndex; i < endIndex; i++) {
            if ((cs[i]) == c) return i;
        }
        return -1;
    }
}

数字略有变化，但速度仍然快得多(省略了 32/64 结果):

short haystack 500k runs
1908 ms for IndexOf16
2361 ms for string.IndexOf
longer haystack:
3061 ms for IndexOf16
3391 ms for string.IndexOf

Update2:这个版本更快(特别是对于长干草堆的情况):

public static unsafe int IndexOf16(string s, int startIndex, char c, int count = -1) {
            if (s == null) throw new ArgumentNullException("s");
            if (startIndex < 0 || startIndex >= s.Length) throw new ArgumentOutOfRangeException("startIndex");
            if (count == -1) count = s.Length - startIndex;
            if (count < 0 || count > s.Length - startIndex) throw new ArgumentOutOfRangeException("count");

            int endIndex = startIndex + count;
            fixed (char* cs = s) {
                char* cp = cs + startIndex;
                for (int i = startIndex; i <= endIndex; i++, cp++) {
                    if (*cp == c) return i;
                }
                return -1;
            }
        }

更新 4: 根据与 LastCoder 的讨论，我认为这取决于架构。我的 Xeon W3550 在工作时似乎更喜欢这个版本，而他的 i7 似乎更喜欢 buildin 版本。我的家用机器 (Athlon II) 似乎介于两者之间。不过，我对巨大的差异感到惊讶。

最佳答案

可能性 1) 这在 C# 中可能不成立(确实如此)，但是当我对 x86-64 汇编程序进行优化工作时，我很快发现在基准测试中从 DLL(标记为外部)调用代码比在我的可执行文件中实现完全相同的函数要慢。最明显的原因是分页和内存，DLL(外部)方法加载到内存中远离其余正在运行的代码，如果之前未访问它，则需要分页。您的基准测试代码应该做您要进行基准测试的函数的一些预热循环，以确保在您为它们计时之前先将它们分页到内存中。

可能性 2) Microsoft 往往不会将字符串函数优化到最充分，因此优化 native 字符串长度、子字符串、indexof 等并非闻所未闻。轶事;在 x86-64 汇编程序中，我能够创建一个版本的 WinXP64 的 RtlInitUnicodeString 函数，它在几乎所有实际用例中的运行速度都快 2 倍。

可能性 3) 您的基准测试代码显示您正在为 IndexOf 使用 2 参数重载，此函数可能调用 3 参数重载 IndexOf(Char, Int32, Int32)，这会为每次迭代增加额外的开销。

这可能会更快，因为您删除了每次迭代的 i 变量增量。

            char* cp = cs + startIndex;
            char* cpEnd = cp + endIndex;
            while (cp <= cpEnd) {
                if (*cp == c) return cp - cs;
                cp++;
            }

edit 出于您的好奇心，我在 2005 年编写了关于 (2) 的回复，用于修补我的 WinXP64 机器的 ntdll.dll。 http://board.flatassembler.net/topic.php?t=4467

RtlInitUnicodeString_Opt: ;;rcx=buff rdx=ucharstr 77bytes
             xor    r9d,r9d
             test   rdx,rdx
             mov    dword[rcx],r9d
             mov    [rcx+8],rdx
             jz     .end
             mov    r8,rdx
   .scan:
             mov    eax,dword[rdx]

             test   ax,ax
             jz     .one
             add    rdx,4
             shr    eax,16
             test   ax,ax
             jz     .two
             jmp    .scan
   .two:
             add    rdx,2
   .one:
             mov    eax,0fffch
             sub    rdx,r8
             cmp    rdx,0fffeh
             cmovnb rdx,rax
             mov    [ecx],dx
             add    dx,2
             mov    [ecx+2],dx
             ret
   .end:
             retn  

edit 2 运行您的示例代码(更新为最快的版本)string.IndexOf 在我的 Intel i7、4GB RAM、Win7 64 位上运行得更快。

short haystack 500k runs
2590 ms for IndexOf16
2287 ms for string.IndexOf
longer haystack:
3549 ms for IndexOf16
2757 ms for string.IndexOf

优化有时非常依赖架构。

关于c# - 为什么我的 string.indexof(char) 更快？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/7172337/