拿這個簡單的比較loopValue == "Firstname"，下面的說法是真的嗎？如果檢查第一個的內部操作數char與比較字符串不匹配，它將提前中止所以采取更原始的形式loopValue，"Firstname"兩者都是[]byte。它會像回調循環一樣遍歷數組：someInspectionFunc(loopValue, "Firstname", func(charA, charB) { return charA == charB})...讓它繼續運行，直到它碰撞false并檢查數量iterations是否等于它們的長度。它也先檢查長度嗎？if len(loopValue) != len("Firstname") { return false}我真的無法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}上面的代碼（尤其是在長字符串上）比只使用v == lookFor.
1 回答
守著星空守著你
TA貢獻1799條經驗 獲得超8個贊
該函數在匯編中處理。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
在調用之前確保字符串的長度相等是編譯器的工作。（該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
}
- 1 回答
- 0 關注
- 196 瀏覽
添加回答
舉報
0/150
提交
取消