split pk 30MB
split 用时52秒
30MB用时间32秒。

速度上汇编代码明显占优。

测试文件是windows 2003 server的iso
--
FROM 101.88.222.*

我在我的系统下也自己写了个版本：https://paste.debian.net/1137584/
操作系统是 Arch (Linux 5.4.28). 分割一个 4.6G 的文件，大小30M，读入和写出的文件都在同一块 SSD 上。测试了一下硬盘速度，读入这个文件大约需要 11s. 运行程序前先运行 sync; echo 1 > /proc/sys/vm/drop_caches 把系统缓存的文件清掉。用 time 记录时间。

split(1):
real    0m22.547s
user    0m0.053s
sys     0m7.705s

我自己写的 mmap split:
real    0m20.439s
user    0m0.011s
sys     0m6.593s

用 strace 跟了下系统调用，split(1) 对输入输出的文件都用 open/read/write/close 操作，读写文件每次都是 128K. 而我的 mmap split 打开待分割文件用了 mmap，然后就是写文件的 open-write-close 循环，每次写文件都是一个 write 写完。
所以在我的系统里面，用 mmap 之后直接读文件并不比多次 read 有明显的速度优势。

【 在 z16166 (z16166) 的大作中提到: 】
: 汇编代码没那么大优势，主要的开销在I/O上，不在于多出来几十条指令。
: 主要可能还是那个file mapping的方案，超大文件一般都用CreateFileMapping。CreateFile也可以指定不要cache（direct I/O）。
--
修改:ArchLinux FROM 114.253.241.*
FROM 114.253.241.*

mmap本来就没有更好的性能表现，非要说，只是省了些内存拷贝和系统调用而已。
【 在 ArchLinux 的大作中提到: 】
: 我在我的系统下也自己写了个版本：https://paste.debian.net/1137584/
: 操作系统是 Arch (Linux 5.4.28). 分割一个 4.6G 的文件，大小30M，读入和写出的文件都在同一块 SSD 上。测试了一下硬盘速度，读入这个文件大约需要 11s. 运行程序前先运行 sync; echo 1 > /proc/sys/vm/drop_caches 把系统缓存的文件清掉。用 time 记录时间。
: split(1):
: ...................
--
FROM 1.202.147.*

windows下这种情况最好是iocp，直接打满磁盘带宽。顺序读写有时候打不满带宽

【 在 javame 的大作中提到: 】
: split pk 30MB
: split 用时52秒
: 30MB用时间32秒。
: ...................
--
FROM 123.116.219.*