Giới thiệu về vấn đề hiệu suất

Quá trình biên dịch dự án Go trên hệ điều hành Windows đôi khi gặp phải tình trạng chậm chạp đáng kể khi thực thi lệnh go build hoặc go list -export, ngay cả trong các trường hợp lẽ ra phải tận dụng được bộ nhớ đệm (cache). Các giải pháp thường thấy trên mạng thường khuyên tắt phần mềm diệt virus hoặc vô hiệu hóa quét đĩa, tuy nhiên ít có tài liệu giải thích cặn kẽ nguyên nhân gốc rễ từ cơ chế hoạt động của trình biên dịch.

Bài viết này sẽ đi sâu vào quy trình thực thi của lệnh build, phân tích cách thức tính toán hash, cơ chế lưu trữ và truy xuất cache để làm rõ lý do gây ra độ trễ trên môi trường Windows.

Cấu trúc thư mục cache

Dữ liệu biên dịch được lưu trữ tại đường dẫn chỉ định bởi biến môi trường GOCACHE. Cấu trúc thư mục này được tổ chức như sau:

go-build
|-- [2 ký tự đầu của hash]
|---- [hash-full]-d  (file kết quả biên dịch: package hoặc binary)
|---- [hash-full]-a  (thông tin action)

Quy trình lưu cache diễn ra theo các bước:

1. Sau khi biên dịch xong một package, nội dung từ thư mục làm việc tạm thời (workDir) sẽ được sao chép vào thư mục GOCACHE.
2. Các file cache này chứa buildID, được tạo thành từ sự kết hợp giữa actionID và contentID. Định dạng thường gặp là <actionId>/<contentId> hoặc có thể lồng nhau tùy thuộc vào dependencies.

Nguyên lý hoạt động của cơ chế cache

Trước khi tiến hành build, hệ thống cần xác định toàn bộ các package phụ thuộc (ImportPath). Quá trình này dựa trên hai khái niệm chính:

• Action Graph (Đồ thị thao tác): Mô tả các thao tác cần thực hiện cho từng package và mối quan hệ phụ thuộc giữa chúng. Các thao tác không có phụ thuộc sẽ được ưu tiên thực hiện trước.
• Biên dịch Package: Dựa trên Action Graph để xác định thứ tự biên dịch, đảm bảo các package phụ thuộc đã hoàn tất trước khi package cha được xử lý.

Cơ chế cache hoạt động bằng cách tính toán hash dựa trên Action Graph trước khi biên dịch. Nếu tìm thấy hash trùng khớp, hệ thống sẽ sử dụng kết quả cũ; ngược lại, quá trình biên dịch mới sẽ diễn ra và kết quả được ghi vào GOCACHE.

Package quản lý cache: go/internal/cache

Package nội bộ này chịu trách nhiệm đọc ghi file cache, tính toán hash và quản lý thời gian sửa đổi. Các chức năng chính bao gồm:

• Tính toán hash từ nội dung byte hoặc từ file cụ thể.
• Truy xuất nội dung cache dựa trên hash (ví dụ: đọc package đã cache, đọc danh sách file go).

Cơ chế sinh Hash trong cache

Tính toán ActionID

Hàm builderActionID chịu trách nhiệm sinh hash cho một thao tác cụ thể, dùng để định danh cache của package đó. Quá trình này sử dụng cache.NewHash với prefix mô tả thao tác (ví dụ: "build " + ImportPath).

Dữ liệu được đưa vào luồng hash bao gồm:

• Phiên bản Go và hệ điều hành.
• Các flag biên dịch.
• Hash nội dung của từng file source (tính qua cache.FileHash).
• ActionID của các package phụ thuộc (import).

Ví dụ về dữ liệu đầu vào để sinh hash cho một package:

HASH NAME: build example.com/project/module
HASH Body:
"go1.21.5"
"compile\n"
"dir /path/to/module\n"
"go 1.17\n"
"goos windows goarch amd64\n"
"file main.go [hash_content]\n"
"import example.com/dep [action_id_hash]\n"
SUM: [final_hash_string]

Các chuỗi hash đi kèm với từ khóa file hoặc import chính là kết quả tính toán từ nội dung file hoặc actionID của dependency. Việc này đòi hỏi rất nhiều thao tác đọc file (IO), đặc biệt khi dự án có nhiều phụ thuộc.

Xác định BuildID và ContentID

BuildID thường có cấu trúc <actionID>/<contentID>. Trong một số trường hợp phức tạp hơn, nó có thể chứa buildID của dependencies lồng nhau. Có thể tách chiết hai thành phần này từ chuỗi buildID hoàn chỉnh:

// Tách lấy phần actionID từ chuỗi buildID
func extractActionPart(identifier string) string {
    sepIndex := strings.Index(identifier, "/")
    if sepIndex < 0 {
        return identifier
    }
    return identifier[:sepIndex]
}

// Tách lấy phần contentID từ chuỗi buildID
func extractContentPart(identifier string) string {
    return identifier[strings.LastIndex(identifier, "/")+1:]
}

Nếu đã có buildID, hệ thống có thể suy ngược lại được actionID và contentID tương ứng.

Quy trình tìm kiếm file cache

Sau khi có được actionID, trình biên dịch sẽ thực hiện kiểm tra cache theo hai phương thức:

1. Kiểm tra file đích (Target): Đọc buildID từ file binary hoặc package đã tồn tại. Nếu buildID này chứa actionID hiện tại, coi như cache hợp lệ.
2. Kiểm tra thư mục GOCACHE: Tìm file có đuôi -a tương ứng với actionID. Nếu tồn tại, đọc nội dung để lấy outputID, sau đó tìm file -d tương ứng để lấy kết quả biên dịch.

Trường hợp file đích đã tồn tại

Đối với các thư viện chuẩn hoặc binary đã được build, hệ thống sẽ đọc trực tiếp buildID nhúng trong file:

// Kiểm tra compile
buildID, err := buildid.ReadFile(targetPath)
if strings.HasPrefix(buildID, currentActionID+"/") {
    // Cache hit
    return true
}

Trường hợp sử dụng cache từ GOCACHE

Đối với các package bên thứ ba, hệ thống tìm kiếm trong thư mục cache:

// Kiểm tra output action
if cachedFile, _, err := cache.GetFile(config, actionHash); err == nil {
    if storedID, err := buildid.ReadFile(cachedFile); err == nil {
        // Sử dụng file từ cache
        return true
    }
}

Công cụ dòng lệnh go tool buildid <file> cũng có thể được sử dụng để kiểm tra thủ công định danh này.

Phân tích nguyên nhân giảm hiệu suất trên Windows

Quá trình sinh hash đòi hỏi đọc nội dung của tất cả các file liên quan và các file phụ thuộc. Trên Windows, các yếu tố sau ảnh hưởng lớn đến tốc độ IO:

• Tốc độ vật lý của ổ đĩa.
• Hệ thống file NTFS có thể chậm hơn so với ext4 (Linux) hoặc APFS (macOS) trong các thao tác đọc ghi nhỏ lẻ.
• Các phần mềm diệt virus hoặc công cụ quét đĩa thực hiện kiểm tra mỗi khi file được truy cập, gây độ trễ cộng thêm.

Đây là lý do việc tắt các công cụ quét nền thường cải thiện đáng kể tốc độ build.

So sánh tốc độ duyệt file giữa Windows và Linux

Đoạn mã dưới đây minh họa sự khác biệt về hiệu suất khi duyệt qua một cấu trúc thư mục lớn chứa nhiều file:

package main

import (
    "log"
    "os"
    "path/filepath"
    "time"
)

func scanDirectory(rootPath string) error {
    return filepath.Walk(rootPath, func(filePath string, stat os.FileInfo, walkErr error) error {
        if walkErr != nil {
            return walkErr
        }
        if !stat.IsDir() {
            // Bỏ qua xử lý để tập trung đo lường tốc độ duyệt
        }
        return nil
    })
}

func main() {
    startTime := time.Now()
    targetFolder := `test_data`
    
    if err := scanDirectory(targetFolder); err != nil {
        log.Fatal(err)
    }
    
    elapsed := time.Since(startTime)
    log.Printf("Thời gian thực thi: %.2f giây", elapsed.Seconds())
}

Kết quả kiểm nghiệm thực tế trên cùng một tập dữ liệu:

• Linux: ~0.06 giây
• Windows: ~2.51 giây

Sự chênh lệch này phản ánh trực tiếp overhead mà go build phải chịu đựng khi tính toán hash cache trên Windows, do tần suất thao tác file hệ thống quá lớn.