VC++ 字串操作效能陷阱：從 strcat 到 CString 內部機制深度解析

前言

將二進位檔案轉為十六進位文字輸出時，發現 lstrcat 導致效能隨字串增長急劇下降。本文深入分析字串連接效能陷阱，從 C 執行庫 strcat 到 MFC CString 內部實作，揭示「黑箱」背後的真相。

效能災難現場

// 初版：使用 lstrcat
void Save()
{
    // ... 讀取檔案到 lpbySrc ...
    for (DWORD i = 0; i < dwSize; i++)
    {
        wsprintf(szByte, (i%16==15) ? _T("%02X\r\n") : _T("%02X "), lpbySrc[i]);
        lstrcat(lpDst, szByte); // 每次都要掃描至字串尾端！
    }
    // 進度條越跑越慢...
}

罪魁禍首：strcat 實作

char* strcat(char* dst, const char* src)
{
    char* cp = dst;
    while (*cp) cp++;        // 1. 尋找結束符 O(n)
    while (*cp++ = *src++);  // 2. 複製內容
    return dst;
}

每次連接都要從頭掃描找 \0，總複雜度 O(n²)。資料量大時明顯拖慢。

優化：手動維護尾端指標

void SaveOptimized()
{
    // ... 讀取檔案 ...
    DWORD j = 0; // 尾端索引
    for (DWORD i = 0; i < dwSize; i++)
    {
        int k = (i%16==15) ? 4 : 3; // "\r\n" 4 字元，否則 3 字元
        wsprintf(szByte, (i%16==15) ? _T("%02X\r\n") : _T("%02X "), lpbySrc[i]);
        lstrcpy(&lpDst[j], szByte); // 直接寫入尾端
        j += k;
    }
    // O(n) 線性複雜度
}

CString 內部機制揭秘

void CString::ConcatCopy(int nSrc1Len, LPCTSTR lpszSrc1, 
                         int nSrc2Len, LPCTSTR lpszSrc2)
{
    int nNewLen = nSrc1Len + nSrc2Len;
    if (nNewLen != 0)
    {
        AllocBuffer(nNewLen);                    // 1. 配置精確大小緩衝區
        memcpy(m_pchData, lpszSrc1, nSrc1Len*sizeof(TCHAR)); // 2. 複製第一段
        memcpy(m_pchData + nSrc1Len, lpszSrc2, nSrc2Len*sizeof(TCHAR)); // 3. 複製第二段
    }
}

• 優點：不需尋找結束符，直接用長度參數定位
• 缺點：每次連接都重新配置記憶體並雙向複製 (operator+= 呼叫 ConcatCopy → 2 次 memcpy)

效能比較總結

* 因每次 += 都重新配置並複製現有內容

核心啟示

「黑箱」並非完美萬能。C 風格字串的「零結尾」機制、CString 的「複製語意」，在特定場景下都會成為效能瓶頸。理解內部實作，才能在關鍵路徑做出正確選擇。

最佳實踐建議

• 大量串流資料：預先配置緩衝區 + 尾端索引寫入
• 已知片段：收集指標/長度陣列，最後一次 Format 或 memcpy 組裝
• 一般邏輯：CString 可讀性優先，效能非瓶頸時無需優化
• 關鍵路徑：Profile 先行，不要過早優化