{ /* nothing */ } instead of the hard-to-see semi, and let's land this bad boy
for Monday's nightlies.

下面回复里说了，周一的nightly会包含这个补丁，大家拭目以待吧

GOLF-AT：
我不知道整个程序代码是什么样子的。我是写程序的，单纯看那段Patch代码，从逻辑角度讲，没有任何意义。这段代码，就是读取两个DLL文件的数据。注意，仅仅是将文件数据读取一遍而已，读出来的数据，没有做任何用途。所以，从逻辑角度来看，没有任何意义，而且是多余的代码。但是，因为Windows缓存的关系，预先读取一遍的话，Windows将文件数据缓存了，才对后面的代码执行效率产生了影响。我看到的Patch代码，没看到32K相关的东西。从逻辑角度来说，加上这段代码，对程序的运行，不会导致任何问题。回到原帖

就是在启动时预读两个dll。而且看代码貌似只读了最头上64k

char buf[64*1024];
DWORD dwBytesRead;
while(ReadFile(fd, buf, sizeof(buf), &dwBytesRead, NULL) && dwBytesRead == sizeof(buf));
CloseHandle(fd);

asdf123456：浏览器大战中最重要的就是速度，各路厂商绞尽脑汁提升产品速度，而比较搞笑的是Windows版Firefox，有一名叫Taras Glek的程序员在Bugzilla提供了开发方并没有发现的一个非常简单的方法，这种只有20行代码，几K大的小补丁可以成倍提升Firefox冷启动速度。这种补丁的原理是在程序预读阶段将XUL的chunks从数M变成32k或者更小，在不影响浏览器功能的前提下即可加速。这种加速方法很可能被正式版本的Firefox使用到，不过由于目前还缺乏测试，请您在应用该补丁时小心为上。

查看:Bug 627591 - preload dlls on windows回到原帖

lz没看懂英文就别乱翻译好不好。直接引用英文原文比自己乱翻译一个靠谱多了。

补丁作者自己的comment：

Basic idea is that the sequential flag + bullshit read tricks windows into
reading xul in 2mb chunks instead of stupid 32k(or smaller) ones. Have to do it
this way because there is no fadvise() on Windows(that I know of)
A big sequential read cuts down on a lot of seeks.

意译过来是：

这个方法的基本理念是，使用sequential flag（看CreateFileA函数的参数FILE_FLAG_SEQUENTIAL_SCAN） + 从文件读一段64k数据，可以使得windows系统以较大的块大小（作者提到2M，未知是否是跟具体系统配置有关）来读取指定的文件，而不是默认的32k或者更小（这个值应该跟系统有关，尤其是文件系统的块大小）。因为windows上没有类似Linux的fadvise()函数直接设定行为。

也就是说，以前的情况是当冷启动时，对于libxul.dll和mozjs.dll这两个最大的dll，需要等windows以较小的块来读取载入。而用了这个补丁，造成windows会以为程序要以顺序读取大文件的方式来读取这两个dll，于是以较大的块读取这两个文件，于是省下了这点时间。作者也提到在他的系统上可以省下2秒时间。

我的理解，这种优化对于profile没什么扩展，脚本等的情况，可以明显作用，因为要读取的文件本来就不多，优化最大的两个文件就可以有比较明显的提升。而如果profile里本来就有很多扩展，脚本等小文件，优化省下的时间相比起来就不是很突出了。现在extension不解压直接load其实也是类似的优化思路。

一个13.3MB，一个1.7MB，比多数人的扩展加起来都要大吧。

我装过最大的扩展是zotero好像也是2mb出头

就是在启动时预读两个dll。而且看代码貌似只读了最头上64k

char buf[64*1024];
DWORD dwBytesRead;
while(ReadFile(fd, buf, sizeof(buf), &dwBytesRead, NULL) && dwBytesRead == sizeof(buf));
CloseHandle(fd);

while(ReadFile(fd, buf, sizeof(buf), &dwBytesRead, NULL) && dwBytesRead == sizeof(buf));
这句话的意思是：每次读取64KB，当读取成功且读取的长度为64KB时就继续循环。当到达文件结尾时，读取的长度为不等于64KB，就不做循环了。
所以说，这段代码，就是打开文件，然后每次读取64KB的数据，当读取成功且读取的长度为64KB时，就继续读取，否则跳出循环，关闭文件。

想知道最新的小时版加上了没有

还没有
美国还在凌晨

while(ReadFile(fd, buf, sizeof(buf), &dwBytesRead, NULL) && dwBytesRead == sizeof(buf));
这句话的意思是：每次读取64KB，当读取成功且读取的长度为64KB时就继续循环。当到达文件结尾时，读取的长度为不等于64KB，就不做循环了。
所以说，这段代码，就是打开文件，然后每次读取64KB的数据，当读取成功且读取的长度为64KB时，就继续读取，否则跳出循环，关闭文件。

你显然漏看了&& dwBytesRead == sizeof(buf)这段。具体作用上面那个回帖已经解释过了。

你显然漏看了&& dwBytesRead == sizeof(buf)这段。具体作用上面那个回帖已经解释过了。

没漏看。 sizeof(buf) 就是 64KB，dwBytesRead 是读取的长度，dwBytesRead == sizeof(buf) 就是读取的长度等于 64KB 时。写了16年的C++程序，这么简单的代码，是不会看错的。

等landed后大家的测试结果。继续3.6路过

啊哈，不知道今天的版本合进去没。

目前依然是Assigned。另外，bugzilla.mozilla.org 网页最上面，刚刚添加了红色文字，说是要做重要的安全更新，可能firefox发现什么严重的安全问题了。

GOLF-AT：目前依然是Assigned。另外，bugzilla.mozilla.org 网页最上面，刚刚添加了红色文字，说是要做重要的安全更新，可能firefox发现什么严重的安全问题了。回到原帖

可能是之前21号的nightly不能自己升级的问题。

另外想想这代码和4.0还是3.x没关系，应该都会用上的。3.6gj

快点合并到3.6.14啊

传入 FILE_FLAG_SEQUENTIAL_SCAN 参数给 CreateFile
会使 顺序读 获得更好的性能,
也就 为后续的那个 while 打铺垫.
读一遍以后 数据 将被 window 操作系统缓存.
然后以后DLL函数调用隐含的文件读就可以命中缓存,
否则每一个新的函数调用都产生硬IO直到文件被全部覆盖完.

现在写程序比较幸福, 很多东西别人都帮你考虑好了,
需要的只是找找API的参数说明.

当年我自学编程, 那时是DOS时代,
读写文件操作系统提供的INT25H和INT26H功能太弱,
我直接去调用BIOS INT13H中断向量.
结果由于程序BUG把硬盘主引导扇区文件分配表那些给重写了....