
1 ysc3839 2025 年 8 月 8 日 14%是怎么看的?任务管理器“进程”那里是不准的,要看“详细信息”。 |
2 ebi5oowiiy1llo 2025 年 8 月 8 日 via Android win 大多数场景性能都略差于 linux ,一方面是微内核,另一方面 linux 全球开发者帮它优化,windows 这时候还在写 w11 bug |
3 Mithril 2025 年 8 月 8 日 没记错的话,Go 的 io.copy 在 Linux 上用的应该是 epoll ,单纯比较极限性能,Windows 上的 IOCP 应该和它差不多,甚至稍好一些。 如果是比较 Windows 和 Linux 的网络性能的话,最好是直接用系统原生的 API ,在物理网卡上跑。 但其实绝大多数情况你压根用不着这么极限的网络性能,有那时间和精力压榨这么点性能不如直接升级硬件。 |
4 DefoliationM 2025 年 8 月 8 日 via Android win 的 io 性能本来就差。 |
5 wuruxu 2025 年 8 月 8 日 win10 讲性能,没有比 linux 好的,就是能跑的软件多 |
6 liuhan907 2025 年 8 月 8 日 Go 没怎么太关心在 Windows 上的性能。以及 IOCP 的模型和 epoll 的模型不兼容,Go 选择了照顾 Linux 环境而加重了 Windows 上的开销。论及纯粹的性能来说 IOCP 比 epoll 强,要到 io_uring 这个接口出现才算打平。 |
9 seWindows OP @Mithril @liuhan907 看了一下源代码,golang 会在每次 fd 操作时进行其余的句柄分离,以确保线程安全。看上去会从原始 Socket 从 IOCP 上解绑。 然后再 RawControl 与 dupSocket 调用获取新句柄,最后再把 newWindowsFile 包装成 *os.File 。 其他复杂的我没有深入追踪,可能和这个有关。每次分离应该都要进入内核态 https://github.com/golang/go/blob/master/src/net/fd_windows.go#L243 如果直接在同一个句柄上循环使用 WSARecv/WSASend 性能应该好得多 。但是对于现在 cpu 性能来说,应该是可以接受的,只会多占用一点 cpu |
10 ysc3839 2025 年 8 月 8 日 via Android @NightFlame 因为任务管理器会用实际的 CPU 使用率乘以 CPU 频率倍数。假如实际的使用率是 10%,CPU 基准频率是 2GHz ,实际频率是 4GHz ,那显示的使用率会是 20%。 |
12 wwqgtxx 2025 年 8 月 8 日 @seWindows 正常的 Read 和 Write 调用根本不会走到那个 dup 的 如果你的说的是两个*net.TCPConn 直接 io.Copy 拷贝的速度,那单纯就是 Linux 下会调用 splice 而 windows 下没这项优化 |
13 seWindows OP |
15 wwqgtxx 2025 年 8 月 8 日 你所看到的所有分离 handle 操作本质上都和这个 issue 有关 https://github.com/golang/go/issues/19098 net 库中正常的 Read 和 Write 以及 ReadFrom/WriteTo 接口实际上都进入了 internal/poll 中使用 execIO 函数调用 iocp 完成,并不会封装成*os.File |
16 opengg 2025 年 8 月 8 日 Windows 是二等公民 |
17 ysc3839 2025 年 8 月 9 日 @NightFlame 是的,详细信息里 CPU 那栏就是 CPU 使用率的百分比 |