我们讲过硬盘的性能特征，主要是针对硬件和操作系统层面进行分析的，现在我们来考虑应用软件层面的差异。
理论上讲，软件可以穿过操作系统直接读取磁盘，但实在太过于麻烦且丧失兼容性，所以几乎不会实践机会，这里就不考虑了，我们只讨论操作系统下的存储形式，主要就是文件了。

文本是最常见的文件格式，它具有通用性易读性等优点而被广泛使用。但是，文本的性能却非常差！
文本字符不能直接运算，需要转换成整数、实数、日期、字符串等内存数据类型才可以进一步处理，而文本的解析是个非常复杂的任务。
举个例子，设想一下把文本“12345" 转成内存整数 12345 的过程：
1) 先设结果的初始值为 0
2) 拆出字符“1”，解析出数值 1，将初值 0 乘以 10 加上这个 1 得到数值 1
3) 再拆出字符“2”，解析出数值 2，把刚才的 1 乘以 10 和这个 2 相加得到数值 12
…

C 程序员都知道用函数 atoi() 可以实现字串到整数的转换，仅仅一句代码，看似非常简单，但其实背后的步骤非常多，CPU 要干很多事才能完成这个动作，耗时并不短。实际过程中还要判断可能出现的非法字符（比如不是数字的字符），比上面描述的步骤还要更复杂得多。
整数还是最简单的数据类型，如果是实数还要处理小数点，字符串解析时要考虑转义字符和引号匹配，日期的解析更是要麻烦得多，因为格式种类太多，2024/1/10 和 10-1-2024 都是常见的合法日期格式，甚至还有 Jan-10 2024 这种，要正确解析，就得尝试用多种格式去匹配，CPU 耗时很严重。

一般来讲，外存数据访问的耗时重点是在硬盘读取上，而文本文件的性能瓶颈却经常发生在 CPU 环节。因为解析的复杂性，CPU 耗时很可能超过硬盘耗时（特别是采用高性能固态硬盘时）。文本是非常慢的，需要高性能处理大数据时不要使用文本！
但是，有些原始数据（如日志）只有文本形式，解析文本就是不可避免的任务。这时候，可以采用并行技术，利用多 CPU 并行度更高的特性，由多个线程同时解析文本，即使仍然串行访问硬盘也能获得更高的处理性能。

如果这些数据如果需要反复使用，那么最好是转换成二进制格式存储，第二次使用不要再解析。
二进制文件中可以将数据类型对应的内存字节直接写出到文件中，再读取时也只要直接取出重新装载成内存数据，没有复杂的解析过程，也不需要判断和识别非法情况，性能就会好很多。
用二进制格式存储数据时需要考虑好压缩手段，否则在某些极端情况下会比文本的存储空间更大，虽然解析时间缩短，但硬盘访问时间会变长。

比如整数 1，用文本存储时只要占一个字节，加上分隔符也就两个字节。而如果要把所有整数都按 32 位整数处理（当前计算机的整数数据类型大多数是这个位长），就要用 4 个字节，比文本大了一倍，有时还要加上数据类型本身的信息，就会更长。
合理的做法是根据数的大小决定位长，比如小整数只存储一个字节或两个字节，大整数才存储更多的字节，因为小整数较常见，结果会使得总体存储空间降低，从而获得性能优势。
当然，压缩率也不是越高越好，解压缩需要消耗 CPU 时间。像上面说的，把整数分大小存储能够减少空间，但在解析时就要多一轮判断，又降低一点性能。采用的压缩方案要在硬盘空间的减少和 CPU 的消耗中取得某种平衡。如果一味地追求压缩率（比如使用 zip 压缩算法），空间是降低得更多，但 CPU 时间将会超过硬盘时间，整体性能反而下降。

比较遗憾的是，业界并没有二进制文件的统一标准，各厂家有各自的样子。二进制文件是可能更快，但是不是真地快，还要看具体格式和实现手段。
比如 Excel 一定程度算是二进制文件，也保存了数据类型。但它同时还保存了许多外观以及单元格之间的关联信息，是个非常复杂的格式，结果 Excel 文件的读写性能还远远不如文本。在导入导出较大数据量且关注性能时就不要用 Excel 格式。
数据库也算是某种二进制格式，通常读写性能会比文本好很多，但是不是能做到最快，还要看它的目标。以交易为目标的 TP 数据库因为要频繁写入，通常不能压缩，存储效率会低。而以计算为目标的 AP 数据库可以使用列式存储来提升压缩率，读取性能就会高很多。
esProc SPL 提供的 btx,ctx 都是比较快的文件格式。btx 使用简单的行式存储，能比文本快 3-5 倍左右，且有 30%-50% 左右的压缩率。ctx 可以在单个文件中实现列存技术，压缩率还能进一步提升，在大多数不需要读出所有列的场景时性能也更好。