核心语言中的字符串比较

3 optimization go

通过这个简单的比较loopValue == "Firstname",以下陈述是真的吗?

如果检查第一个的内部操作数char与比较的字符串不匹配,它将提前中止

所以采取原始形式loopValue,"Firstname"都是[]byte.它会的阵列有点像,从而为真理回调循环:

someInspectionFunc(loopValue, "Firstname", func(charA, charB) {
    return charA == charB
})
Run Code Online (Sandbox Code Playgroud)

...让它继续前进,直到碰撞false并检查它们的数量iterations是否等于它们的长度.还先检查长度吗?

if len(loopValue) != len("Firstname") {
    return false
}
Run Code Online (Sandbox Code Playgroud)

我无法go在GitHub 的源代码中找到解释,因为它有点高于我.

我之所以这么说是因为我正在进行大数据处理,并且正在进行基准测试,并进行CPU,内存和分配,pprof以便从流程中挤出更多的数据.从那个过程开始,它让我想到Go(也是一般的C)会在幕后做到这一点.这是完全在汇编级别还是比较已经在本机Go代码中发生(有点像上面的代码片段中描绘的那样)?

如果我太模糊或错过了什么,请告诉我.谢谢

更新

当我firstCharater在大字符串中进行比赛时json,在真正比较之前,我得到了3.7%100k重量级条目的基准测试增益:

<some irrelevant inspection code>.. v[0] == firstChar && v == lookFor {
    // Match found when it reaches here
}
Run Code Online (Sandbox Code Playgroud)

上面的代码(特别是在长字符串上)比以前更快v == lookFor.

Jim*_*imB 6

该功能在汇编中处理.amd64版本是:

TEXT runtime·eqstring(SB),NOSPLIT,$0-33
    MOVQ    s1str+0(FP), SI
    MOVQ    s2str+16(FP), DI
    CMPQ    SI, DI
    JEQ eq
    MOVQ    s1len+8(FP), BX
    LEAQ    v+32(FP), AX
    JMP runtime·memeqbody(SB)
eq:
    MOVB    $1, v+32(FP)
    RET
Run Code Online (Sandbox Code Playgroud)

并且编译器的工作是确保字符串在调用之前具有相同的长度.(该runtime·memeqbody函数实际上是优化内存比较发生的地方,但可能没有必要在此处发布全文)

等效的Go代码是:

func eqstring_generic(s1, s2 string) bool {
    if len(s1) != len(s2) {
        return false
    }
    for i := 0; i < len(s1); i++ {
        if s1[i] != s2[i] {
            return false
        }
    }
    return true
}
Run Code Online (Sandbox Code Playgroud)