我们讲过硬盘的性能特征，主要是针对硬件和操作系统层面进行分析的，现在我们来考虑应用软件层面的差异。

理论上讲，软件可以穿过操作系统直接进行磁盘扇区的访问，但实在太过于麻烦而几乎不会实践机会，这里就不考虑了，我们只讨论操作系统下的存储形式，而文件就是其中重要的存储形式。

文件一般有两种：文本文件和二进制文件，我们分别来讨论。

文本文件

文本是很常见的数据存储形式，它具有通用性易读性等优点而被广泛使用。但是，文本的性能却非常差！

文本字符不能直接运算，需要转换成整数、实数、日期、字符串等内存数据类型才可以进一步处理，而文本的解析是个非常复杂的任务。

举个例子，设想一下把文本“12345" 转成内存二进制整数 12345 的过程：

1. 先设结果的初始值为 0

2. 拆出字符“1”，解析出数值 1，将初值 0 乘以 10 加上这个 1 得到数值 1

3. 再拆出字符“2”，解析出数值 2，把刚才的 1 乘以 10 和这个 2 相加得到数值 12

4. 再拆出字符“3”，解析出数值 3，把刚才的 12 再乘以 10 加上这个 3 得到数值 123

5. …

有些 C 程序员知道用函数 atoi() 可以实现字串到整数的转换，仅仅一句代码，看似非常简单，但其实背后的步骤非常多，CPU 要干很多事才能完成这个动作，耗时并不短。实际过程中还要判断可能出现的非法字符（比如不是数字的字符），比上面描述的步骤还要更复杂得多。

整数还是最简单的数据类型，如果是实数还要处理小数点，字符串解析时要考虑转义字符和引号匹配，日期的解析更是要麻烦得多，因为格式种类太多，2018/1/10 和 10-1-2018 都是常见的合法日期格式，甚至还有 Jan-10 2018 这种，要正确解析，就得尝试用多种格式去匹配，CPU 耗时很严重。

一般来讲，外存数据访问的主要时间是在硬盘本身的读取上，而文本文本的性能瓶颈却经常发生在 CPU 环节。因为解析的复杂性，CPU 耗时很可能超过硬盘耗时（特别是采用高性能固态硬盘时）。文本是非常慢的，需要高性能处理大数据时不要使用文本！

但是，有些原始数据（如日志）只有文本形式，解析文本就是不可避免的任务。这时候，一方面可以采用并行技术，利用多 CPU 并行度更高的特性，由多个线程同时解析文本，这样即使仍然串行访问硬盘也能获得更高的文本处理性能；另一方面，这些数据如果需要反复使用，那么最好是转换成二进制格式存储，第二次使用不要再次解析。

二进制文件

二进制文件中，我们会将各种数据类型对应的内存字节直接写出到文件中，再读取时也只要直接取出重新装载成内存数据，没有复杂的解析过程，也不需要判断和识别非法情况，这时性能就会好很多。

不过，用二进制数据存储时需要考虑好压缩手段，否则在某些极端情况下会比文本的存储空间更大，虽然解析时间缩短，但硬盘访问时间会变长。

比如整数 1，用文本存储时只要占一个字节，即使加上分隔符也就两个字节。而如果要把所有整数都按 32 位整数处理（当前计算机的整数数据类型大多数是这个位长），就需要用 4 个字节来存储，比文本大了一倍，有时可能还要加上数据类型本身的信息，就会更长。

对于这种情况，合理的做法是根据数的大小决定位长，比如小整数只存储一个字节或两个字节，大整数才存储更多的字节，因为小整数较常见，结果会使得总体存储空间降低，从而获得性能优势。

但是，压缩率并不是越高越好，解压缩需要消耗 CPU 时间。象上面说的，把整数分大小存储能够减少空间，但在解析时就要多一重判断，又降低一点性能。最后采用的压缩方案，要在硬盘空间的减少和 CPU 的消耗中取得某种平衡。如果一味地追求压缩率（比如使用 zip 压缩算法），空间是降低得更多，但 CPU 时间将会超过硬盘时间，整体性能反而下降。

不过，无论如何，二进制文件仍然是更快的存储格式。采用简单压缩方案的二进制文件，即使同样采用行式存储，一般也能达到比文本高 4-5 倍的性能。二进制格式还有可能使用分段并行技术和列存技术，获得更高的性能。