[民科]多图杀狐狸测试

不知道什么时候听说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）

不错的压力测试。
基本上验证了我们对于FF和Chrome打开大量图片时候的观感。

从载入速度来看，我认为和Gecko和Webkit引擎有关系，Webkit明显比Gecko轻量快速，客观造就在图片生成渲染载入速度上Webkit有优势。
从浏览速度来看，因为Gecko是占用较多内存载入所有图片，因此在流畅性上没话说。
从卡顿来看，应该是FF在载入大量图片时候启动了GC和CC回收内存造成的卡顿。而听说Chrome实现了IGC，而FF还没实现，因此FF卡顿更为明显。而这个也造成了FF浏览大量图片时候内存占用高且不易释放的问题。

先大概看一下，回头详细的再慢慢看。 <!-- s8) --><img src="{SMILIES_PATH}/icon_cool.gif" alt="8)" title="Cool" /><!-- s8) -->

没比较过。和渲染机制有关？

报告给bugzilla？

这个应该也会很卡，但不耗内存

这个bug，几年前就有人报过了，是渲染机制的问题，没什么改进进度。
其他浏览器是只解码页面可见部分的图片的，gecko是全页面解码，所以速度内存都差很多。

谢谢楼上的提醒~
仔细搜索了一下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团队们早日开发出牛逼的方案了~~

我觉得这个更接近解决

https://bugzilla.mozilla.org/show_bug.cgi?id=683286

我关注这两个
https://bugzilla.mozilla.org/show_bug.cgi?id=689623
https://bugzilla.mozilla.org/show_bug.cgi?id=661304
动静虽有
但是进度不足
早呢

这个要像chrome学习，解决多图网页内存占用、内存释放和网页流畅性的问题。

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

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

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

BT网站，看看你的FireFox能不能坚持住 • Mozilla Firefox中文社区
6年的发展 依然任重道远

dgod：这个bug，几年前就有人报过了，是渲染机制的问题，没什么改进进度。
其他浏览器是只解码页面可见部分的图片的，gecko是全页面解码，所以速度内存都差很多。回到原帖

没有几年吧，主要是4之后才是这样的，正式版到现在还不到一年。3.6也卡，但不会占这么多内存然后崩溃

dindog：
没有几年吧，主要是4之后才是这样的，正式版到现在还不到一年。3.6也卡，但不会占这么多内存然后崩溃回到原帖

有几年了，我找到的最老的相关bug是https://bugzilla.mozilla.org/show_bug.cgi?id=296818
一直没有根本解决，到现在有解决方案了https://bugzilla.mozilla.org/show_bug.cgi?id=542158，但没有进度。

smoke：BT网站，看看你的FireFox能不能坚持住 • Mozilla Firefox中文社区
6年的发展 依然任重道远
回到原帖

2G内存没抗住，后面内存不够了疯狂读写硬盘，卡了一阵Firefox直接崩溃了连带x桌面也崩溃了。