|
45楼#
发布于：2011-04-28 10:37
huhuhu：昨天看了看javascript，现学现用写了一个简单的测试网页，就是多图的页面的读取。我的想法是把一个多图网页存成本地文件，然后用FF以幻灯片形式一张一张播放图片（间隔500ms）。相当于我们经常用的滚屏看图吧，有两种方式读取。一种是网页加载时预读所有图片，然后播放。还有一种是不预读实时解码播放。图片就是本帖网页的那些图。我取了300张。测试结果如下： 赞测试，这么看来fx3.6确实是如大家所说，内存管理方便没有释放的情况 我的理念是，未解码的图像通常是jpg，体积不会很大，因此应该优先缓存到内存中。而解码后的图片是原始格式，总量可能非常大，因此应该实时释放。 考虑到恢复关闭标签页的功能，如果可以将未解码数据存到内存/磁盘缓存中（也就是恢复标签所用缓存），那么就不矛盾了：可恢复的数据只是未解码的图像，比如那个考据贴，即使可以恢复，也只会占用60M空间而已，考虑到页面架构等，应该不会超过200M占用。作为可恢复的代价是可接受的（而不是现在这样1G多） 此外，你提到：“3：Nightly预读所有图片，打开网页后内存峰值达到1G左右,预读完后无任何变化还是1G,播放时内存略微增加。” 不光要看内存，因为win7显示的只是物理内存，应该更多的关注右下角的提交大小，那是真正占用的线性储存空间的指标。在我这里，浏览的过程中增加的提交大小和预读时瞬间增长的大小几乎相同（考虑到你只用了300图片，300-500,1G-1.3G，可以认为我们的效果是等价的），因此我猜测，在你浏览的过程中，虽然物理内存没有变化（有波动，或许就是你说的略微增加），但是提交大小还是又增长了一倍。 也就是我的疑惑：第一次大量的数据是在预读什么？解码图片并放入内存？那么浏览过程中增长的内存又是什么？再解码一次放入内存？ Chrome在浏览的过程中也会增长占用，总的大小和firefox相仿，和Fx区别就是没有刚打开时的那个1.3G的预读 |
|
|
|
46楼#
发布于：2011-04-28 10:37
huhuhu：昨天看了看javascript，现学现用写了一个简单的测试网页，就是多图的页面的读取。我的想法是把一个多图网页存成本地文件，然后用FF以幻灯片形式一张一张播放图片（间隔500ms）。相当于我们经常用的滚屏看图吧，有两种方式读取。一种是网页加载时预读所有图片，然后播放。还有一种是不预读实时解码播放。图片就是本帖网页的那些图。我取了300张。测试结果如下： 这测试是有益的，也凸显出问题所在。可是有一点和实际使用不符，就是读取的是本地文件，速度当然不会太慢。 |
|
|
|
47楼#
发布于：2011-04-28 10:37
dindog： 具体的说，firefox是一款以gecko为排版引擎xulrunner为运行库的跨平台浏览器，firefox的排版引擎对系统的依赖性很低。对firefox来说，各平台下不同的仅为UI及其相关的区别.... 另外对载入和拖动，firefox与其他浏览器是有所不同的，firefox是一次性全部载入并解析排版，而拖动浏览的时候，绝大多数属于显卡或CPU的事，内存波动是很低的....个人觉得，一次性将网页全部载入并解析确实不太合理 |
|
|
48楼#
发布于：2011-04-28 10:37
昨天看了看javascript，现学现用写了一个简单的测试网页，就是多图的页面的读取。我的想法是把一个多图网页存成本地文件，然后用FF以幻灯片形式一张一张播放图片（间隔500ms）。相当于我们经常用的滚屏看图吧，有两种方式读取。一种是网页加载时预读所有图片，然后播放。还有一种是不预读实时解码播放。图片就是本帖网页的那些图。我取了300张。测试结果如下：
1：FF3.6 预读所有图片，打开网页后内存峰值达到1G左右，预读完后逐渐回落最后稳定在100M左右，播放幻灯片时，内存基本不超过200M。（加载时间很长） 2：FF3.6不预读图片，播放图片时，实时从硬盘读取解码。打开网页后由于没有预读内存占用一直是120M左右。（加载时间短，播放时和有预读无差别） 3：Nightly预读所有图片，打开网页后内存峰值达到1G左右,预读完后无任何变化还是1G,播放时内存略微增加。（加载时间很长，不流畅，这是我机器太老的问题） 4：Nightly不预读图片，播放图片时，实时从硬盘读取解码。打开网页后由于没有预读内存占用一直是130M左右（加载时间短，播放时比有预读流畅，因为预读后未释放内存，内存耗尽，都在调用缓存） 5：最后不死心用Opera试了试，很奇怪的是，两个测试在OP下完全一样，好像OP根本不把图片解压到内存里（不管有没有预读），而是全部实时解压。不过播放时同样无差别。 我的感觉是，把图片解压后放到内存里在浏览时没有太大作用，反而加大了加载时间，我们不可能同时浏览超过10张图片，那么把所有图片解压后放进内存有没有必要？实时解压对图片来说已经很快了，实在嫌慢的话，预读解压一小部分进内存也是可以的。我想问问有没有强制FF不解压图片到内存的函数或方法？想学学写个脚本来改善这种情况。下面是我的测试网页。 <html>
<head>
<script type="text/javascript">
aimg =new Array;
for(i=0;i<300;i++){aimg[i]=new Image();aimg[i].src="file:///C:/Documents%20and%20Settings/Administrator/%E6%A1%8C%E9%9D%A2/img/"+i+".jpg"}//预读图像
var c=0
var t
function timedCount()
{
var w= window.open(aimg[c].src,"test","chrome,width=800,height=600");
c=c+1
t=setTimeout("timedCount()",500)
if(c>100){clearTimeout(t);w.close()}
}
</script>
</head>
<body>
<form>
<input type="button" value="开始！" onClick="timedCount()">
</form>
<p>请点击上面的按钮。幻灯片形式展示图片。</p>
</body>
</html> |
|
|
|
49楼#
发布于：2011-04-28 10:37
就我观察，载入和浏览拖动是不一样的。就是平台不一样造成结果相差较大，我也不认同把责任都推到windows上，前有自己的firefox3.6，后有opera，chrome甚至IE都在我的机器上都没问题。 profile是新开的profile，也可以排除非主流设置和扩展的因素 |
|
|
|
50楼#
发布于：2011-04-28 10:37
那个网页，我的FF内存占用在943M，虚拟内存在1G多
|
|
|
51楼#
发布于：2011-04-28 10:37
这算不算无力的辩驳.......
现在在公司，流量有限制，晚上回去下载你的附件，然后截图相关数据 |
|
|
52楼#
发布于：2011-04-28 10:37
说道最后你还是没有下载我的附件罢。
|
|
|
|
53楼#
发布于：2011-04-28 10:37
白左：那还真是委屈你了，认真的测试者。我们结果的不同只是因为你没有看见“完全载入”四个字而已。然后你拒不承认这个简单的错误，导致现在下不了台，值得么 第三张图，你显然没看，net Down示波最低，即下载已停止 浏览器左下角也没有Transferring date from.......页面拖动至最下方 请教工程师，你所认为的完全载入究竟是怎么样的？:D 说你没仔细看贴倒也一点都没错，下得了台下不了台，委屈不委屈，为啥又要扯到这些有的没的方面？实际上由于你看贴没看仔细，才多出来那么多的无聊....明天假期，正好我今天也无聊 这世界最可爱的人，就是那些自以为周围看官均附和自己.....的人 另外狂读硬盘的人.....看下自己的配置吧，虚拟内存是由系统和软件双方面来调度的...另外firefox4的内存释放bug，我从来没有否认过... 有条件的同学看下吧，是否真的吃4.2G资源.... 不过话说回来，linux user基本倒也知道，windows xp对内存的调度能力，确实是很差的，内存释放在XP时代被用户熟悉，据$M说，windows 7就没有所谓的内存释放.......linux就没有这些有的没的事 |
|
|
54楼#
发布于：2011-04-28 10:37
|
|
|
55楼#
发布于：2011-04-28 10:37
那还真是委屈你了，认真的测试者。我们结果的不同只是因为你没有看见“完全载入”四个字而已。然后你拒不承认这个简单的错误，导致现在下不了台，值得么
当然，我没有用加粗红色大号字体标明测试条件是我的失误，不过在你之前有很多狐友“意会”了我的前提条件，导致我以为大家都能理解。 所以你现在可以下载我亲自上传的附件，然后把那个该死的htm丢掉你的火狐子里去，然后我们的测试条件就一样了。如何？ |
|
|
|
56楼#
发布于：2011-04-28 10:37
非xp系统不知道，xp（我想win 7 vista也一样）下，4.0之后的版本就是一个扩展不装，打开那个网页我是没法用的。后期直接就是硬盘读写动作和卡机。。。1g内存的路过。
内存是小，但问题是明显的，包括firefox 3.6在内的其它所有主流浏览器都能正常浏览。定性不要什么精确实验吧。 系统都不一样，大家其实都是数据不充分就没必要说话刀光剑影的 |
|
|
|
57楼#
发布于：2011-04-28 10:37
悲剧的是chromium在linux下的I/O开销是非常大的.....压根就不敢去尝试
|
|
|
58楼#
发布于：2011-04-28 10:37
操作系统不同，相互比较似乎有所不妥。
既然有linux能不能比较一下同是linux下，opera以及chrome等的表现情况。 |
|
|
59楼#
发布于：2011-04-28 10:37
这句话我不知道你是在自嘲还是怎样，我是一个工程师，我只相信实验结果，其他一律是放屁。 如果这个也能算作实验的话，我无话可说 哦，工程师，久仰久仰，不过工程师和这个主题无关，扯这个没有实际意义，难道我表明我是项目经理的话，看官就更信任我的话了？ 我所列出的图片上的数据很清楚，截图右侧的conky中显示的firefox men占用百分比，整个系统消耗men百分比，I/O消耗示波，net up/down示波，时间等等，基本均在conky上..... 只能说你只相信你实验的结果，而其他人的数据，对你来说就是放屁，是否这个意思？另外我只是以我的数据说话，客观的说，我以我的数据对比你的数据得出的可能的结论，讨论中压根不存在谁对或者谁错？你觉得你是否太激动了点？危言耸听不是指责，而是将个人独有现象覆盖群体现象的一种表现。我没有说你夸大你的数据，我只是分析你的数据的可靠性，我想知道这究竟是你独有的现象还是个群体的现象。你应该以全新的系统运行裸firefox，并以专有监视软件来记录一步一步的数据。如果我真想驳斥你的话，我可以已老旧系统装十几个扩展后，长时间运行的firefox一步一步得出的数据即可。不过这完全没有必要。我只是做了firefox的观察，结论与你的数据完全不同，这就够了。 再说一句，没有指责，无所谓对错，只是探讨这究竟是你独有的现象，还是个群体的现象，究竟是firefox mem bug的引申？还是firefox处理图片，javascript等的bug?如果是独有的现象，而被大众拿来宣传的话，显然对firefox不公平 也来消歧义，看图，mem包含 used free shared buffers cached，分别表示使用 剩余 共享 缓冲区 缓存。swap类似windows中的虚拟页面文件。-buffers/cache表示被程序吃掉的数据，交换分区就不说了，除了大型镜像或媒体文件外，基本用不到，而我使用如此大型的swap也只是为了系统hibernate而已..... |
|
|
