Go文件读取性能在Windows与WSL2 Linux差异悬殊及pprof疑问

以下是代码（main.go） #

package main

import (
    "fmt"
    "io"
    "os"
    "time"
)

func read(accumulatorSize, readBufSize int) {
    buf := make([]byte, readBufSize)
    f, _ := os.Open("dump.txt")
    defer f.Close()
    var n int64
    var took time.Duration

    start := time.Now()
    for {
        delta, err := f.Read(buf)
        if err == io.EOF {
            break
        } else if err != nil {
            fmt.Println(err)
            return
        }
        n += int64(delta)
        if n >= int64(accumulatorSize) {
            break
        }
    }
    took = time.Since(start)
    fmt.Printf("Read: read buffer size %d, read total %d, took %v\n", readBufSize, n, took)
}

func main() {
    MB := 1024 * 1024
    KB := 1024
    FILESIZE := 100 * MB
    read(FILESIZE, 1*KB)
    read(FILESIZE, 512*KB)
}

运行结果（go run main.go） #

Windows系统 #

Read: read buffer size 1024, read total 104857600, took 201.3612ms
Read: read buffer size 524288, read total 104857600, took 15.792ms

Linux系统（WSL2后端容器） #

Read: read buffer size 1024, read total 104857600, took 17.092969328s
Read: read buffer size 524288, read total 104857600, took 120.544513ms

Linux环境下还尝试了pprof分析

发现pprof记录的时间远短于程序实际运行时间。

技术疑问解答 #

1. 为何Windows与WSL2 Linux环境下的Go文件读取性能差异如此巨大？ #

核心原因在于WSL2的架构特性：

• 跨文件系统桥接开销：如果测试用的dump.txt存储在Windows的NTFS文件系统中，WSL2访问时需要经过虚拟机与宿主系统之间的文件系统桥接层，每次IO操作都要跨虚拟机边界，带来额外的上下文切换、数据拷贝成本。小缓冲区（1KB）场景下IO次数极多，这种开销被成倍放大，导致性能暴跌；大缓冲区（512KB）减少了IO次数，差距有所缩小，但仍高于Windows本地。
• 文件缓存机制差异：WSL2的文件缓存策略与Windows本地不同，小批量读取时缓存命中率更低，进一步加剧性能差距。
• 虚拟磁盘IO限制：WSL2的虚拟磁盘本身的IO性能，尤其是随机小IO场景，不如Windows本地直接访问物理磁盘的效率。

2. 当进程处于睡眠状态时，pprof是否会停止记录？ #

是的。pprof的CPU profiling默认基于CPU时钟中断采样，仅统计进程占用CPU（用户态或内核态运行）的时间。当进程因等待IO完成（如调用read时阻塞）进入睡眠状态时，进程不占用CPU资源，这部分等待时间不会被pprof采样统计，因此pprof记录的时间远短于程序实际运行时间（实际运行时间包含了睡眠等待的耗时）。

内容的提问来源于stack exchange，提问作者DTS SPC