[民科]多图杀狐狸测试

不知道什么时候听说fx也分段浏览了，高兴了一把，生成了一个测试页面，结果还是失望了……结果如下。

测试页面构成：
纯<img />，一共280p，每p为简单构图的png图片，大小24,304字节，压缩档总大小6.5M左右
未压缩档理论上为800*800*24/8=1920000字节，即1.83M，280p恰好512M左右。

物理内存占用对比：（由上至下 [当前profile]firefox 11b4  vs  [3个插件]chromium 16.0.894.0  vs  [空白profile]fx 11b4）

图片：memo.png

结果诠释：
打开浏览器（红色标记）测试开始后过程分为四个阶段，A打开测试页面直到载入完成（黄色区段的斜坡部分），B用中键引导方式快速浏览完整个页面（橙色区段），C鼠标按住滚动条快速在整个页面滚来滚去（红色区段），D切换到空白tab直到浏览器自动释放测试页面（黄色标记）

Firefox：
从图中可以看出，A阶段花费了5秒钟左右，在此期间内存飙升，由之前的测试可知，如果此页面容量更大，很容易造成不稳定继而崩溃。
中间有个凹陷是因为切到about:memory看太久导致释放了= =b
空白profile表现好很多，大概只花费了2秒左右
完全载入后的memory：

793.69 MB (100.0%) -- explicit
├──690.60 MB (87.01%) -- images
│  ├──690.36 MB (86.98%) -- content
│  │  ├──690.36 MB (86.98%) -- used
│  │  │  ├──683.67 MB (86.14%) -- uncompressed-heap
│  │  │  ├────6.69 MB (00.84%) -- raw
│  │  │  └────0.00 MB (00.00%) -- (1 omitted)
│  │  └────0.00 MB (00.00%) -- (1 omitted)
│  └────0.24 MB (00.03%) -- (1 omitted)

B阶段可以看出，在全部图片uncompressed的情况下，浏览页面依然需要额外的内存，而且并不会释放
C阶段现有profile没有做，因为太卡了。从空白profile可以看出，快速的定位/浏览仍然会造成较大幅度的内存波动。
由黄色标记开始的D阶段可以看出，默认情况下20秒左右就会释放背景tab的内存，比之前的默认值短了很多（但是不能从根本上解决问题啊大大

Chromium
没啥好说的，除了抓住滚动条疯狂卷动会造成轻微的内存波动，内存占用一直差不多。





浏览体验：
fx现有profile：载入很慢，浏览过程流畅。
fx空白profile：载入较快，浏览过程流畅。
cr：秒开，浏览过程流畅。

稳定性：
fx：内存波动非常大，大页面时容易造成不稳定。
cr：即时解码CPU要求比较高，从中键锚点浏览时速度没有fx空白profile快可以看出来，内存占用可以忽略，稳定。

综合体验：
  考虑到6M的图片对应的uncompressed图片体积可能非常大，本测试是具有实际意义的。完全下载完毕整个页面的图片可能并不需要多少时间，尤其是多图页面，一般会少于浏览所需时间，理想情况下可以假设打开页面后短时间内已经载入完成。
  对于A阶段，这个5秒钟/2秒钟/秒开更取决于下载网速，可以认为没有区别；对于本地保存的网页，区别明显。

  B阶段可以认为是必经阶段，因为你打开一个网页的目的肯定是浏览吧。对于网络浏览，通常在同一个页面花费的时间较长，CPU的工作可以分散到更长的时间中进行，对提升cr的浏览体验是有利的，而内存占用的时间越长显然越不好，因此对fx是不利的；对本地网页，浏览时更不会在意那一点点的CPU占用，而在本测试中，一个总资源只有6M的网页却占用了700M以上的内存，显然是非常不利的。

  C阶段无论在网络浏览还是本地浏览都是非常重要的，对于在页面内查找信息，随机读取显然是必要的可能步骤，用内存换速度的fx略有优势。实际测试时，无论是现有profile还是空白profile，本地快速卷动时的流畅度都要比chromium顺滑，但是CPU占用并没有特别大的优势，在我的AMD X2 245上，快速卷动时chromium需要70%波动，fx需要50%波动

  D阶段对cr没有意义，而对fx是个致命伤，尤其是大页面……对本地浏览，通常需要的只是当前网页，查找到所需信息过后就关闭，影响不大。对网络浏览……想象一下你终于刷开了一个巨型图贴，浏览到一半时发现了一个关键字，于是你打开google花了几分钟了解了这个关键字的出处和含义，再切回来的时候卡了5秒钟，浏览器失去响应……不幸的是，正是因为是大型页面，包含的信息多，你需要到其他页面查询信息的几率会比简单页面更大。



测试结果如上。
个人的意见是，这种以tab为单位，把整个页面载入到内存中的做法对于一般网页的浏览体验提升还不错，但是对于小内存用户和大页面恰恰成为了软肋。现在信息爆炸，大容量页面网站也多了起来，所以这些大块头对狐狸的杀伤能力不可忽视。
目前只和chromium做过对比，只了解chrome/chromium的图片缓存行为
不知道其他浏览器还有没有什么更先进的管理方案？fx团队对这个问题是怎么看的？大家的意见如何，讨论讨论吧~


测试页面下载（啊你没看错，只有19K）
ImageHeavyTest.7z

类型：

售价：0

大小：20KB

下载：67次

描述：

[下载]

*edit*
以上是基于正常浏览中的模拟情况，下面还有一个极端压力测试。正常情况下能够在16GB内存以下的机器上确保一次完美的Out of Memory Firefox Kill （<ゝω·）~☆Kira
OOM KILL.7z

类型：

售价：0

大小：64KB

下载：91次

描述：

[下载]

（2048*4096 x 340p -> 8GB uncompressed image data）

谢谢楼上的提醒~
仔细搜索了一下bugzilla，相比2010年那时起，又多了不少的bug提交，共同点是都没有解决~
Jeff Muizelaar在Bug 661304中说，

For what it's worth, it seems like Chrome just does a synchronous decode on draw to avoid this problem. I haven't yet looked at how they do discarding.

= =b 那么现在只好默默地祈祷fx团队们早日开发出牛逼的方案了~~

fang5566：既然是排版引擎，那就不好办咯，gecko引擎比较臃肿，虽然很强大，但是要改动的话，量比较大。回到原帖

是呀，对于这样的非盈利开源项目来说，工作量也是一个很重要的障碍……

在bangumi征求了一堆勇士挑战，结果如下：
总样本数：25
[list=1]Firefox
OS娘中枪 x2
屎掉 x4
载入不全 x2[/list:o]

[list=2]Chrome
毫无鸭梨 x7[/list:o]

[list=3]Opera
毫无鸭梨 x4[/list:o]

[list=4]IE9
屎掉 x1
载入不全 x3[/list:o]
[list=5]
Safari
毫无鸭梨 x2[/list:o]

[list=6]IE8
渣渣不提也罢
不过也有人报告毫无鸭梨哇[/list:o]


结论，除了狐狸，没有其他浏览器有此问题。或许这是gecko的历史遗留问题？

bluec：这里有个ppt，讲fx的内存问题的 http://blog.mozilla.com/nnethercote/201 ... nsumption/回到原帖

大致扫了扫，太专业鸟，应该是给developer看的吧