阅读:14651回复:84
关于内存使用的疑问
偶然接觸了一個超大网页后才发现的。这里是小圆脸的一个考据贴。不完全保存下来后有58M的样子
http://www.gcforum.org/viewthread.php?tid=5721 保存下来后,用浏览器打开,奇妙的事情发生了 IE9 :很奇怪的不知道为什么阻挡了图片,不好作为对比,弃权 Firefox 4.0.1 (29扩展) : 内存占用如第一张附图 Firefox 6a1 (无扩展) :内存占用用第二张附图 Chromium(12): 内存占用如第三张附图 从图可见,无论有没有扩展,firefox的内存占用在加载网页后极具增长,我的内存已经不够以至于被削尖了……剩下的塞到虚拟内存去了,实际的占用甚至远远大于这个值。而且可以看见增长速度非常惊人,在拖拽网页后,从正常的200M猛增到1G多…… 而Chrome几乎没什么内存变动…… 从效果上而言,二者基本相同,所有的图片,文字,样式都是完整显示的。 我奇怪的是,为什么一个总量58M的网页会需要那么多内存显示?为什么chrome又不需要?机理是啥?然后我以为是某个插件的问题,于是拿纯净版的Fx6测试,结果内存依然飙升……参见图三中的两个尖峰…… 是我不小心设置了什么地方吗? 然后我最想问的还是,为什么一个58M的网页需要上G的内存来显示…… [s]如果有必要的话,我可以把已保存的网页上传来测试……就是那个58M的……[/s] *edit* 上传了,大家可以自己试试打开这个网页不同浏览器占用的内存……另外测试前先保护好你的重要网页,firefox基本一定会崩的…… http://u.115.com/file/f0bec6fb08 |
|
|
1楼#
发布于:2011-04-28 10:37
chrome今天早上更新的正式版,完全打开你这个页面稳定在144M这样子
|
|
2楼#
发布于:2011-04-28 10:37
|
|
|
3楼#
发布于:2011-04-28 10:37
试试这几个选项,看看有没有改善
// 图片内存管理设置 pref("image.mem.discardable", true); pref("image.mem.decodeondraw", true); pref("image.mem.min_discard_timeout_ms", 5000); |
|
|
4楼#
发布于:2011-04-28 10:37
lord:试试这几个选项,看看有没有改善 参见这个帖子https://g.mozest.com/thread-38497-1-1 都没用。因为现在的问题是一加载页面Firefox就立刻开始读取,和解码与否关系不大 第一个只是开关是否丢弃(默认开启),第二个是改变解码时机,第三个是超时时间,只决定未显示的图片丢弃的时间而已。改为100ms后测试结果如图,在两个tab间切换时的内存简直是…… 只要我还停留在那个tab,内存占用就不会像chrome那样低 如果连接到原始帖子,chrome的做法是只下载,不解码也不读取(?),内存毫无变动,随着浏览的进行才会把图片加载到内存中。而firefox则是全部加载,大量内存被分配给根本看不到的部分,这样不合理吧- - |
|
|
5楼#
发布于:2011-04-28 10:37
打开那网页,我的都没超过300M呢
打开那网页,我的都没超过300M呢 |
|
6楼#
发布于:2011-04-28 10:37
re lord
仔细想了想,discard时间应该影响不大,但是decodeondraw应该正是我所需要的!但是改了之后没效果(当然重启过),一载入网页还是一下子就全部decode, 把内存占满了… |
|
|
7楼#
发布于:2011-04-28 10:37
好吧,从I/O消耗来看,个人宁愿浏览器尽量使用内存,而不要频繁的从缓存读到内存.....
楼主用专门的软件测下chrome打开那页面,拖动,硬盘是否一直频繁的读操作? |
|
8楼#
发布于:2011-04-28 10:37
另外about:config
image.cache.size image.mem.max_bytes_for_sync_decode 这两个值你设置下 |
|
9楼#
发布于:2011-04-28 10:37
我咋感觉改选项是有用的呢
chrome和fx都开单页,载入一阵子后(都未完全载入),鼠标滚动浏览到20%处 结果:差不多 |
|
|
10楼#
发布于:2011-04-28 10:37
占用确实很惊人
另外IE8的,也将近用来1G |
|
11楼#
发布于:2011-04-28 10:37
We're Sorry
Firefox had a problem and crashed. We'll try to restore your tabs and windows when it restarts. To help us diagnose and fix the problem, you can send us a crash report. |
|
12楼#
发布于:2011-04-28 10:37
|
|
|
13楼#
发布于:2011-04-28 10:37
|
|
|
14楼#
发布于:2011-04-28 10:37
测试了一下,载入网页时二者都是慢慢内存升高,如温水煮青蛙,对比意义不大
【附图A】 (话说咱论坛怎么插附件图 下面是载入本地保存页面的结果 Firefox4.0.1 【附图B】 第一图Fx是一开始就decode了本页所有图片然后塞入内存,可见内存占用非常高,注意下方的提交,虚拟内存已经到上限了…… 第二图是上下拖动,保证所有图片都decode后测试网页的最大内存占用,惊人的储存空间占用…… 第三图是关闭后的效果 Chromium 12 【附图C】 第一图最左边是Cr刚载入的时候,内存占用可以忽略,可以肯定只decode了当前屏幕,或者几个屏幕的图片,右边是刚开始以较快速度使用中键浏览模式移动,在第一次到1G内存的时候出现了一个奇怪的释放,之后我使用按住滚动条快速卷动,直到底部,之后没有出现释放。此时内存占用没有达到最大值 第二图是上下卷动,确保所有图片都已经decode,内存占用不再增加后的最大内存占用值。虽然提交数要比firefox小近1个G,但是进程选项中显示值和firefox差不多,1.6G 第三图是关闭后的内存。 结果分析: 最大载入状态下,二者的内存占用都是1.5G左右,这是和网页相关的一个属性,所以可以看出,要完整显示整个网页,除了增加内存别无他法。虽然提交大小chrome比Firefox小近1G,不过这说明不了什么问题。 而Chrome的decodeondraw只在第一次载入的情况下生效,一旦浏览完整个网页,内存占用只比Fx4小500M~1G左右,原因是第一次占用到1G时意味不明的释放行为。 整体浏览行为对比(有实验支撑) 消歧义: 内存 - 指性能页左边显示的绿条,代表物理内存的占用情况 提交 - 性能页右下角的提交显示,其值=物理内存+虚拟内存,代表程序运行所需的线性储存空间 Fx4: *首次读取:读入整个网页,decode所有图片(理由是内存飚增,性能页的提交涨到3G左右)。 *浏览过程:在浏览过程中内存(进程页)显示不变,1.5G左右,但是性能页的提交会随着浏览渐渐增加(特别的,当第一次内存到1G左右时会有一个释放行为,参见图片,其后没有) *完全加载:完全浏览完页面,提交最终涨到4.2G左右……(- -|||)并且随时间推移不会释放 *切换tab:切换tab时不释放,直到达到设定的discard时间(默认2分钟),或者有恢复关闭页面。 *关闭tab:关闭tab时纯洁profile的行为未知,有恢复关闭页面扩展的情况下不释放。 Chromium12: *首次读取:读入当前屏幕和整个网页的非多媒体部分(如js等),不会decode其他部分的图片(理由是内存几乎没有变化) *浏览过程:在浏览过程中内存和提交随着浏览进程升高,在第一次达到1G的时候会有一个释放行为(见图中的折线),然后一路涨到最高值 *完全加载:完全浏览完页面,提交最终涨到3G左右……随时间推移不会释放(slimx所说的不会降下来) *切换tab:切换tab时立即释放所有提交。再次切换回来时重新开始首次读取的行为,即浏览到的地方才decode。也就是说,除非你一直停留在此界面浏览,否则只要有一次切换tab的行为就不会导致内存达到最大值(比如Fx惊人的4.2G……) *关闭tab:关闭tab时纯洁profile完全释放提交和内存 结论: 就图片性能管理这一方面个人感觉Firefox完全没有Chromium做得好。 首先从性能分析上讲,Firefox从第一次载入页面后就会一直处于最大内存占用情况,并且在载入或者一段时间后切换标签过去的一瞬间会有非常迅速的内存暴涨过程,这样的冲击对于程序稳定性是非常不利的,很可能造成失去响应或者崩溃。而chrome的理念则是实时加载,一有机会就释放,保证低内存的情况下正常显示所有图片。并且,一旦切换标签就释放所有decoded数据,虽然听起来好像挺笨。但是实际上,decode的速度是非常快的,从Fx首次载入全部图片那一刻就能看出来,decode1.5G的图片塞满你的内存只需要几秒,考虑到内存速度,瓶颈可能还不是decode本身,而是写入内存。至少在我的机器上,chrome实时decode从未出现图片延迟显示的情况,即使按住滚动条急速卷动——只有内存在飚而已 然后从浏览体验上讲,一个页面一打开就失去响应,另一个页面立刻就显示,而且二者浏览时没什么大区别,显然后者更流畅。不光是已保存网页,哪怕是实时载入网页,你总会切到其他tab干别的事等待载入吧,而chrome切换即释放的特性保证在这个过程中内存一直处于低水平。注意是释放decode数据,图片本身还在内存里,不牵涉到虚拟内存效率,更不牵涉到硬盘IO,就效率上讲,没有什么劣势。 我最不能理解的是,如果Fx预先decode了页面所有图片,为什么浏览时提交还会疯长?以至于最后同样的页面涨到4.2G提交,比chrome多1.2G……把我的内存+虚拟内存全部吃完了…… 当然没有用纯洁的profile测试是我的失误,这1.2G的差别有可能是扩展的问题。 不管是不是扩展的问题……总之Fx这样一口气吞掉的行为相当于一个冲击,对稳定性是非常不利的。切换tab释放就不要求了,因为这是恢复关闭页面的必然代价。现在就希望能看一点给我decode一点,不要像默认大家都是4G内存一样一下子就把整个页面吃下去(而且浏览过程中提交还会涨……不知道为什么…… |
|
|
上一页
下一页