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

就是在启动时预读两个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时，就继续读取，否则跳出循环，关闭文件。

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

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

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其实也是类似的优化思路。

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);

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

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

光说没用

meat：stupid 32k。。。其实是个简单思路啊，东西成了定式就一直这样搞了那么多年

有时程序员也是死脑筋的，呵呵。回到原帖

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

是不是已经加进每夜版里面呢？我的64位B10昨天的每夜版已经秒开了

meat：stupid 32k。。。其实是个简单思路啊，东西成了定式就一直这样搞了那么多年

有时程序员也是死脑筋的，呵呵。回到原帖

都是非常固执的家伙，firefox完全可以在打开后再检测扩展和软件的更新。。。。。。。。他们非要先检测在打开

fiey：中文翻译是不是有误呢  
不是一次读一点 32k
而是一次读2m 这样
32k 对SSD来说 简直是小case
但对于机械硬盘来说
就是灾难 囧
回到原帖

翻译是错了
stupid 32k。。。其实是个简单思路啊，东西成了定式就一直这样搞了那么多年

有时程序员也是死脑筋的，呵呵。

另外这个patch很快会整合，因为好像实际变动不多，对各方面影响较小

Should land on Monday's Nightly. :-k
https://bugzilla.mozilla.org/show_bug.cgi?id=627591
Makes Cold Startup 50% faster on Windows. \:D/

快来了。

中文翻译是不是有误呢  
不是一次读一点 32k
而是一次读2m 这样
32k 对SSD来说 简直是小case
但对于机械硬盘来说
就是灾难 囧

和网络优化一样的
堆一堆 一次性读取

PS. 自己编译不行的
可以期待第三方编译版嘛
比如tete 和 陵川

这个要重新编译源程序，不是普通人可以用的。

应该怎么使用才是我想问的……0_0