鉴于这功能有限的编辑器不能输入表格，需要良好排版的请转移到博客，只看文字的请继续====>点我转移到博客看<====
首先，这是对分页读取法在C#2.0下的性能测试实验，其次，它也是让我回忆起以前C语言的分页读写、汇编的分字节乘除、单片机的分段执行这些招数的「化整为零大法」。Read extreme large files using pagingby Nobi Conmajia ([email protected])May 15th, 2012
我们在编程过程中，经常会和计算机文件读取操作打交道。随着计算机功能和性能的发展，我们需要操作的文件尺寸也是越来越大。在.NET Framework中，我们一般使用FileStream来读取、写入文件流。当文件只有数十kB或者数MB时，一般的文件读取方式如Read()、ReadAll()等应用起来游刃有余，基本不会感觉到太大的延迟。但当文件越来越大，达到数百MB甚至数GB时，这种延迟将越来越明显，最终达到不能忍受的程度。通常定义大小在2GB以上的文件为超大文件（当然，这个数值会随着科技的进步，越来越大）。对于这样规模的文件读取，普通方法已经完全不能胜任。这就要求我们使用更高效的方法，如内存映射法、分页读取法等。内存映射（Memory Mapping）内存映射的方法可以使用下面的Windows API实现。
LPVOID MapViewOfFile(HANDLE hFileMappingObject,
DWORD dwDesiredAccess,
DWORD dwFileOffsetHigh,
DWORD dwFileOffsetLow,
DWORD dwNumberOfBytesToMap);虽然使用方便，但使用上限制较多，比如规定的分配粒度（Windows下通常为64KB）等。分页读取法（Paging）另外一种高效读取文件的方法就是分页法，也叫分段法（Segmentation），对应的读取单位被称作页（Page）和段（Segment）。其基本思想是将整体数据分割至较小的粒度再进行处理，以便满足时间、空间和性能方面的要求。分页法的概念使用相当广泛，如嵌入式系统中的分块处理（Blocks）和网络数据的分包传输（Packages）。
在开始研究分页法前，先来看看在超大文件处理中，最为重要的问题：高速随机访问。桌面编程中，分页法通常应用于文字处理、阅读等软件，有时也应用在大型图片显示等方面。这类软件的一个特点就是数据的局部性，无论需要处理的文件有多么大，使用者的注意力（也可以称为视口ViewPort）通常只有非常局部的一点（如几页文档和屏幕大小的图片）。这就要求了接下来，我们要找到一种能够实现高速的随机访问，而这种访问效果还不能和文件大小有关（否则就失去了高速的意义）。事实上，以下我们研究的分页法就是利用了「化整为零」的方法，通过只读取和显示用户感兴趣的那部分数据，达到提升操作速度的目的。参考上图，假设计算机上有某文件F，其内容为「01234567890123456」（引号「」中的内容，不含引号，下同），文件大小为FileLength=17字节，以PageSize=3对F进行分页，总页数PageCount=6，得到页号为0~5的6个页面（图中页码=页号+1）。各页面所含数据如下表所示。
页号 页码 内容 至头部偏移量 （Hex） 长度
0 1 012 00 01 02 3
1 2 345 03 04 05 3
2 3 678 06 07 08 3
3 4 901 09 0a 0b 3
4 5 234 0c 0d 0e 3
5 6 56 0f 10 2
可以看到，最后一页的长度为2（最后一页长度总是小于PageSize）。当我们要读取「第n页」的数据（即页码=n）时，实际上读取的是页号PageNumber=n-1的内容。例如n=3时，PageNumber=2，数据为「678」，该页数据偏移量范围从0x06至0x08，长度为3（PageSize）。为便于讲述，在此约定：以下文字中，均只涉及页号，即PageNumber。参考图2，设当PageNumber=x时，页x的数据范围为[offsetStart, offsetEnd]，那么可以用如下的代码进行计算（C#2.0）。 offsetStart = pageNumber * pageSize;if(offsetStart + pageSize < fileSize)
offsetEnd = offsetStart + pageSize;
else
offsetEnd = fileSize - 1;我们常用的System.IO.FileStream类有两个重要的方法：Seek()和Read()。// 将该流的当前位置设置为给定值。
public override long Seek (
long offset,
SeekOrigin origin
)
// 从流中读取字节块并将该数据写入给定缓冲区中。
public override int Read (
[InAttribute] [OutAttribute] byte[] array,
int offset,
int count
)
利用这两个方法，我们可以指定每次读取的数据起始位置（offsetStart）和读取长度（offsetEnd - offsetStart），这样就可以读到任意指定的页数据。我们可以遍历读取所有页，这就相当于普通读取整个文件（实际操作中，一般不会有需求一次性读取上GB的文件）。指定PageNumber，读取页数据
byte[] getPage(Int64 pageNumber)
{
if (fileStream == null || !fileStream.CanSeek || !fileStream.CanRead)
return null;
if (pageNumber < 0 || pageNumber >= pageCount)
return null;
// absolute offileStreamet of read range
Int64 offsetStart = (Int64)pageNumber * (Int64)pageSize;
Int64 offsetEnd = 0;
if (pageNumber < pageCount - 1)
{
// not last pageNumber
offsetEnd = offsetStart + pageSize - 1;
}
else
{
// last pageNumber
offsetEnd = fileSize - 1;
}
byte[] tmp = new byte[offsetEnd - offsetStart + 1];
fileStream.Seek(offsetStart, SeekOrigin.Begin);
int rd = fileStream.Read(tmp, 0, (Int32)(offsetEnd - offsetStart + 1));
return tmp;
}由于每次读取的数据长度（PageSize）远远小于文件长度（FileSize），所以使用分页法能够只读取程序需要的那部分数据，最大化提高程序的运行效率。下表是笔者在实验环境下对分页法读取文件的运行效率的测试。CPU：Intel Core i3 380M @ 2.53GHz内存：DDR3 2048MB x2硬盘：TOSHIBA MK3265GSX (320 GB) @ 5400 RPM为尽量保证测试质量，测试前系统进行了重装、硬盘整理等维护操作。该硬盘性能测试结果如下图所示。 下面是为了测试分页法而制作的超大文件读取器界面截图，图中读取的是本次试验的用例之一Windows8消费者预览版光盘镜像（大小：3.40GB）。本次测试选择了「大、中、小」3种规格的测试文件作为测试用例，分别为： # 文件名 文件内容 大小（KB）
1 AlishaHead.png Poser Pro 6贴图 11,611
2 ubuntu-11.10-desktop-i386.iso Ubuntu11.10桌面版镜像 711,980
3 Windows8-ConsumerPreview-64bit-ChineseSimplified.iso Windows8消费者预览版64位简体中文版镜像 3,567,486
通过进行多次读取，采集到如下表A所示的文件读取数据结果。表中项目「分页(单页)」表示使用分页读取法，但设置页面大小为文件大小（即只有1页）进行读取。同样的，为了解分页读取的性能变化情况，使用普通读取方法（一次读取）采集到另一份数据结果，如下表B所示。对用例#1，该用例大小仅11MB，使用常规（单次）读取方法，仅用不到20ms即将全部内容读取完毕。而当采用分页法，随着分页大小越来越小，文件被划分为更多的页面，尽管随机访问文件内容使得文件操作更加方便，但在读取整个文件的时候，分页却带来了更多的消耗。例如当分页大小为1KB时，文件被分割为11,611个页面。读取整个文件时，需要重复调用11,611次FileStream.Read()方法，增加了很多消耗，如下图所示。（图中数据仅为全文读取操作对比）从图中可以看到，当分页尺寸过分的小（1KB）时，这种过度追求微粒化反而导致了操作性能下降。可以看到，即实现了微粒化，能够进行随机访问，同时仍保有一定量的操作性能，分页大小为64KB和1MB是不错的选择。实际上，上文介绍的MapViewOfFile函数的推荐分页大小正是64KB。对用例#2，该用例大小为695.29MB，达到较大的尺寸，因此对读取缓存（cache）需求较高，同时也对合适的分页尺寸提出了要求。可以看到，和用例#1不同，当文件尺寸从11.34MB增加到近700MB时，分页尺寸随之相应的扩大，是提高操作性能的好方法（下图中1MB分页）。对用例#3，该用例达到3.4GB大小，符合我们对超大文件的定义。通过前述2个用例的分析，可以推测，为获得最佳性能，分页大小需继续提高（比如从1MB提高到4MB）。由于本次试验时间仓促，考虑不周，未使用「边读取、边丢弃」的测试算法，导致分页读取用例#3的数据时，数据不断在内存中积累，最终引发System.OutOfMemoryException异常，使得分页读取完整文件这项测试不能正常完成。这一问题，需在下次的试验当中加以解决和避免。尽管如此，通过试验，仍然可以清楚的看到，在常规文件（GB以下级别）操作中，分页法具有高度灵活性，但额外开销大，全文读取速度慢的问题。当操作超大文件（GB以上级别）时，分页法的优势开始显现。极高的数据读取灵活性带来的是和文件大小无关的随机页面访问速度（仅和分页大小有关）。在这个级别上，文件大小往往远远超过常规方法所能读取的最大值（0x7FFFFFFF），因此只有使用分页法，积少成多，才能完成读取完整文件的工作。分页法使用简单，思路清晰，具有很高的灵活性和与文件长度无关的随机读取能力，最大支持文件大小理论上能够达到8,388,608 TB（Int64）。但同时它也具有额外开销大的特点，因此不适合小文件的操作。通过扩展该方法，我们可以几乎在所有需要大量、重复、大范围算法处理的程序中加以应用分页法的「化整为零」思想，以减少计算粒度，实现计算的可持续进行。分页法，以及上文提到的内存映射法，其实均早已出现多年，更是广泛应用于各个行业。笔者之所以仍旧撰写此文，一则锻炼自己的编程能力、语言归纳能力、文字写作能力，二则加深对方法的理解，通过试验得出的现象来深入方法的本质。鉴于笔者才疏学浅，在此妄言，有些词不达意，甚至出现谬误之处，还望各位读者多加批评、指正。 野比春熊[email protected] 15th, 2012（全文完）
首先，这是对分页读取法在C#2.0下的性能测试实验，其次，它也是让我回忆起以前C语言的分页读写、汇编的分字节乘除、单片机的分段执行这些招数的「化整为零大法」。Read extreme large files using pagingby Nobi Conmajia ([email protected])May 15th, 2012
我们在编程过程中，经常会和计算机文件读取操作打交道。随着计算机功能和性能的发展，我们需要操作的文件尺寸也是越来越大。在.NET Framework中，我们一般使用FileStream来读取、写入文件流。当文件只有数十kB或者数MB时，一般的文件读取方式如Read()、ReadAll()等应用起来游刃有余，基本不会感觉到太大的延迟。但当文件越来越大，达到数百MB甚至数GB时，这种延迟将越来越明显，最终达到不能忍受的程度。通常定义大小在2GB以上的文件为超大文件（当然，这个数值会随着科技的进步，越来越大）。对于这样规模的文件读取，普通方法已经完全不能胜任。这就要求我们使用更高效的方法，如内存映射法、分页读取法等。内存映射（Memory Mapping）内存映射的方法可以使用下面的Windows API实现。
LPVOID MapViewOfFile(HANDLE hFileMappingObject,
DWORD dwDesiredAccess,
DWORD dwFileOffsetHigh,
DWORD dwFileOffsetLow,
DWORD dwNumberOfBytesToMap);虽然使用方便，但使用上限制较多，比如规定的分配粒度（Windows下通常为64KB）等。分页读取法（Paging）另外一种高效读取文件的方法就是分页法，也叫分段法（Segmentation），对应的读取单位被称作页（Page）和段（Segment）。其基本思想是将整体数据分割至较小的粒度再进行处理，以便满足时间、空间和性能方面的要求。分页法的概念使用相当广泛，如嵌入式系统中的分块处理（Blocks）和网络数据的分包传输（Packages）。
在开始研究分页法前，先来看看在超大文件处理中，最为重要的问题：高速随机访问。桌面编程中，分页法通常应用于文字处理、阅读等软件，有时也应用在大型图片显示等方面。这类软件的一个特点就是数据的局部性，无论需要处理的文件有多么大，使用者的注意力（也可以称为视口ViewPort）通常只有非常局部的一点（如几页文档和屏幕大小的图片）。这就要求了接下来，我们要找到一种能够实现高速的随机访问，而这种访问效果还不能和文件大小有关（否则就失去了高速的意义）。事实上，以下我们研究的分页法就是利用了「化整为零」的方法，通过只读取和显示用户感兴趣的那部分数据，达到提升操作速度的目的。参考上图，假设计算机上有某文件F，其内容为「01234567890123456」（引号「」中的内容，不含引号，下同），文件大小为FileLength=17字节，以PageSize=3对F进行分页，总页数PageCount=6，得到页号为0~5的6个页面（图中页码=页号+1）。各页面所含数据如下表所示。
页号 页码 内容 至头部偏移量 （Hex） 长度
0 1 012 00 01 02 3
1 2 345 03 04 05 3
2 3 678 06 07 08 3
3 4 901 09 0a 0b 3
4 5 234 0c 0d 0e 3
5 6 56 0f 10 2
可以看到，最后一页的长度为2（最后一页长度总是小于PageSize）。当我们要读取「第n页」的数据（即页码=n）时，实际上读取的是页号PageNumber=n-1的内容。例如n=3时，PageNumber=2，数据为「678」，该页数据偏移量范围从0x06至0x08，长度为3（PageSize）。为便于讲述，在此约定：以下文字中，均只涉及页号，即PageNumber。参考图2，设当PageNumber=x时，页x的数据范围为[offsetStart, offsetEnd]，那么可以用如下的代码进行计算（C#2.0）。 offsetStart = pageNumber * pageSize;if(offsetStart + pageSize < fileSize)
offsetEnd = offsetStart + pageSize;
else
offsetEnd = fileSize - 1;我们常用的System.IO.FileStream类有两个重要的方法：Seek()和Read()。// 将该流的当前位置设置为给定值。
public override long Seek (
long offset,
SeekOrigin origin
)
// 从流中读取字节块并将该数据写入给定缓冲区中。
public override int Read (
[InAttribute] [OutAttribute] byte[] array,
int offset,
int count
)
利用这两个方法，我们可以指定每次读取的数据起始位置（offsetStart）和读取长度（offsetEnd - offsetStart），这样就可以读到任意指定的页数据。我们可以遍历读取所有页，这就相当于普通读取整个文件（实际操作中，一般不会有需求一次性读取上GB的文件）。指定PageNumber，读取页数据
byte[] getPage(Int64 pageNumber)
{
if (fileStream == null || !fileStream.CanSeek || !fileStream.CanRead)
return null;
if (pageNumber < 0 || pageNumber >= pageCount)
return null;
// absolute offileStreamet of read range
Int64 offsetStart = (Int64)pageNumber * (Int64)pageSize;
Int64 offsetEnd = 0;
if (pageNumber < pageCount - 1)
{
// not last pageNumber
offsetEnd = offsetStart + pageSize - 1;
}
else
{
// last pageNumber
offsetEnd = fileSize - 1;
}
byte[] tmp = new byte[offsetEnd - offsetStart + 1];
fileStream.Seek(offsetStart, SeekOrigin.Begin);
int rd = fileStream.Read(tmp, 0, (Int32)(offsetEnd - offsetStart + 1));
return tmp;
}由于每次读取的数据长度（PageSize）远远小于文件长度（FileSize），所以使用分页法能够只读取程序需要的那部分数据，最大化提高程序的运行效率。下表是笔者在实验环境下对分页法读取文件的运行效率的测试。CPU：Intel Core i3 380M @ 2.53GHz内存：DDR3 2048MB x2硬盘：TOSHIBA MK3265GSX (320 GB) @ 5400 RPM为尽量保证测试质量，测试前系统进行了重装、硬盘整理等维护操作。该硬盘性能测试结果如下图所示。 下面是为了测试分页法而制作的超大文件读取器界面截图，图中读取的是本次试验的用例之一Windows8消费者预览版光盘镜像（大小：3.40GB）。本次测试选择了「大、中、小」3种规格的测试文件作为测试用例，分别为： # 文件名 文件内容 大小（KB）
1 AlishaHead.png Poser Pro 6贴图 11,611
2 ubuntu-11.10-desktop-i386.iso Ubuntu11.10桌面版镜像 711,980
3 Windows8-ConsumerPreview-64bit-ChineseSimplified.iso Windows8消费者预览版64位简体中文版镜像 3,567,486
通过进行多次读取，采集到如下表A所示的文件读取数据结果。表中项目「分页(单页)」表示使用分页读取法，但设置页面大小为文件大小（即只有1页）进行读取。同样的，为了解分页读取的性能变化情况，使用普通读取方法（一次读取）采集到另一份数据结果，如下表B所示。对用例#1，该用例大小仅11MB，使用常规（单次）读取方法，仅用不到20ms即将全部内容读取完毕。而当采用分页法，随着分页大小越来越小，文件被划分为更多的页面，尽管随机访问文件内容使得文件操作更加方便，但在读取整个文件的时候，分页却带来了更多的消耗。例如当分页大小为1KB时，文件被分割为11,611个页面。读取整个文件时，需要重复调用11,611次FileStream.Read()方法，增加了很多消耗，如下图所示。（图中数据仅为全文读取操作对比）从图中可以看到，当分页尺寸过分的小（1KB）时，这种过度追求微粒化反而导致了操作性能下降。可以看到，即实现了微粒化，能够进行随机访问，同时仍保有一定量的操作性能，分页大小为64KB和1MB是不错的选择。实际上，上文介绍的MapViewOfFile函数的推荐分页大小正是64KB。对用例#2，该用例大小为695.29MB，达到较大的尺寸，因此对读取缓存（cache）需求较高，同时也对合适的分页尺寸提出了要求。可以看到，和用例#1不同，当文件尺寸从11.34MB增加到近700MB时，分页尺寸随之相应的扩大，是提高操作性能的好方法（下图中1MB分页）。对用例#3，该用例达到3.4GB大小，符合我们对超大文件的定义。通过前述2个用例的分析，可以推测，为获得最佳性能，分页大小需继续提高（比如从1MB提高到4MB）。由于本次试验时间仓促，考虑不周，未使用「边读取、边丢弃」的测试算法，导致分页读取用例#3的数据时，数据不断在内存中积累，最终引发System.OutOfMemoryException异常，使得分页读取完整文件这项测试不能正常完成。这一问题，需在下次的试验当中加以解决和避免。尽管如此，通过试验，仍然可以清楚的看到，在常规文件（GB以下级别）操作中，分页法具有高度灵活性，但额外开销大，全文读取速度慢的问题。当操作超大文件（GB以上级别）时，分页法的优势开始显现。极高的数据读取灵活性带来的是和文件大小无关的随机页面访问速度（仅和分页大小有关）。在这个级别上，文件大小往往远远超过常规方法所能读取的最大值（0x7FFFFFFF），因此只有使用分页法，积少成多，才能完成读取完整文件的工作。分页法使用简单，思路清晰，具有很高的灵活性和与文件长度无关的随机读取能力，最大支持文件大小理论上能够达到8,388,608 TB（Int64）。但同时它也具有额外开销大的特点，因此不适合小文件的操作。通过扩展该方法，我们可以几乎在所有需要大量、重复、大范围算法处理的程序中加以应用分页法的「化整为零」思想，以减少计算粒度，实现计算的可持续进行。分页法，以及上文提到的内存映射法，其实均早已出现多年，更是广泛应用于各个行业。笔者之所以仍旧撰写此文，一则锻炼自己的编程能力、语言归纳能力、文字写作能力，二则加深对方法的理解，通过试验得出的现象来深入方法的本质。鉴于笔者才疏学浅，在此妄言，有些词不达意，甚至出现谬误之处，还望各位读者多加批评、指正。 野比春熊[email protected] 15th, 2012（全文完）
PS:直接操作Position属性即可，无需Seek