x******n 发帖数: 9057 | 1 10M元素的整数数组,SpiderMonkey(firefox的javascript引擎)消耗存储40MB,一点
浪费没有(很强啊,它怎么存储这个额外的null值呢。。),SquirrelFish(Safari)消
耗48MB,也不错,V8(Chrome)消耗100MB。
然后把这10M元素反向排序(就是赋值是0-9999999,然后由大到小排序),
SpiderMonkey额外消耗内存80MB,耗时16秒;SquirrelFish额外消耗120MB,耗时19秒
;V8排序1M元素(注意,是1M)的类似数组消耗内存过G,耗时不知道多长,我等不及
把进程kill了(这倒也不一定是V8自己就这么差,可能是Chrome提供的Shell有问题,
虽然按理说不应该会有这么大的overhead)。
作为对照,Python存储10M元素的整数数组消耗内存160M,排序几乎是瞬间完成。
然后我对比测试了下SpiderMonkey(SM)和SquirrelFish(SF):
SM存储一个字符串额外的overhead大约25字节左右,每个字符2字节(JS都是unicode)
SF存储一个字符串额外overhead 160字节左右,每个字符2字节
Python存储一个字串overhead 24字节,每个字符1字节
上面说的都是ascii字符串。
SM和SF数组的额外overhead都是70字节左右。
测试了一些数学运算和字符串操作,速度上SF~Python>V8>SM
总的来说SM和SF用来编桌面程序的性能还是可以的,跟python可比拟,不过都有些
gotcha需要注意。。。 |
b*****l 发帖数: 9499 | 2 wk,刚把主力浏览器从 FF 换到了 Chrome 上来。。。
【在 x******n 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 10M元素的整数数组,SpiderMonkey(firefox的javascript引擎)消耗存储40MB,一点 : 浪费没有(很强啊,它怎么存储这个额外的null值呢。。),SquirrelFish(Safari)消 : 耗48MB,也不错,V8(Chrome)消耗100MB。 : 然后把这10M元素反向排序(就是赋值是0-9999999,然后由大到小排序), : SpiderMonkey额外消耗内存80MB,耗时16秒;SquirrelFish额外消耗120MB,耗时19秒 : ;V8排序1M元素(注意,是1M)的类似数组消耗内存过G,耗时不知道多长,我等不及 : 把进程kill了(这倒也不一定是V8自己就这么差,可能是Chrome提供的Shell有问题, : 虽然按理说不应该会有这么大的overhead)。 : 作为对照,Python存储10M元素的整数数组消耗内存160M,排序几乎是瞬间完成。 : 然后我对比测试了下SpiderMonkey(SM)和SquirrelFish(SF):
|
x******n 发帖数: 9057 | 3 马上FF4的js引擎性能还会大幅提升,IE9的性能也非常不错,感觉现在大家都重视了,
再往后浏览器之间js引擎的速度差异不会大了。当然取决于实现还是会有不同的gotcha.
【在 b*****l 的大作中提到】![](/moin_static193/solenoid/img/up.png) : wk,刚把主力浏览器从 FF 换到了 Chrome 上来。。。
|
b*****l 发帖数: 9499 | 4 觉得对于比较单一的浏览习惯来说,chrome 比 FF 还是有优势的,快很多。
gotcha.
【在 x******n 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 马上FF4的js引擎性能还会大幅提升,IE9的性能也非常不错,感觉现在大家都重视了, : 再往后浏览器之间js引擎的速度差异不会大了。当然取决于实现还是会有不同的gotcha.
|
x******n 发帖数: 9057 | 5 是快一点,也没有很多吧,omnibar也不错。
不过ff功能更全面,也更省内存。
chrome主要太喜欢开进程了,tab少的时候进程也不关,我经常4,5个tab,有10几个
chrome进程在运行。。。
还有就是我上次说的redraw的问题,现在最新版好像好了很多,不过偶尔还是会出现。
但是现在新版多了个讨厌的问题。。就是右下角的chrome图标,我打开一个新tab,准
备输地址,这个时候都要用余光看看右下角的输入法是不是开着,如果开着要关掉。
chrome的那个图标让我老以为输入法开着。。。你难道没遇到这个问题么。。
【在 b*****l 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 觉得对于比较单一的浏览习惯来说,chrome 比 FF 还是有优势的,快很多。 : : gotcha.
|
b*****l 发帖数: 9499 | 6 右下角。。。啥都没有啊。。。
【在 x******n 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 是快一点,也没有很多吧,omnibar也不错。 : 不过ff功能更全面,也更省内存。 : chrome主要太喜欢开进程了,tab少的时候进程也不关,我经常4,5个tab,有10几个 : chrome进程在运行。。。 : 还有就是我上次说的redraw的问题,现在最新版好像好了很多,不过偶尔还是会出现。 : 但是现在新版多了个讨厌的问题。。就是右下角的chrome图标,我打开一个新tab,准 : 备输地址,这个时候都要用余光看看右下角的输入法是不是开着,如果开着要关掉。 : chrome的那个图标让我老以为输入法开着。。。你难道没遇到这个问题么。。
|
r****y 发帖数: 26819 | 7 应该测试一下mac下的safari
【在 x******n 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 10M元素的整数数组,SpiderMonkey(firefox的javascript引擎)消耗存储40MB,一点 : 浪费没有(很强啊,它怎么存储这个额外的null值呢。。),SquirrelFish(Safari)消 : 耗48MB,也不错,V8(Chrome)消耗100MB。 : 然后把这10M元素反向排序(就是赋值是0-9999999,然后由大到小排序), : SpiderMonkey额外消耗内存80MB,耗时16秒;SquirrelFish额外消耗120MB,耗时19秒 : ;V8排序1M元素(注意,是1M)的类似数组消耗内存过G,耗时不知道多长,我等不及 : 把进程kill了(这倒也不一定是V8自己就这么差,可能是Chrome提供的Shell有问题, : 虽然按理说不应该会有这么大的overhead)。 : 作为对照,Python存储10M元素的整数数组消耗内存160M,排序几乎是瞬间完成。 : 然后我对比测试了下SpiderMonkey(SM)和SquirrelFish(SF):
|
x******n 发帖数: 9057 | 8 空白页的右下角,没有?你什么版本?
【在 b*****l 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 右下角。。。啥都没有啊。。。
|
r****y 发帖数: 26819 | 9 我以前嫌ff太费内存的时候做过比较,最后还是回到ff继续用。
【在 x******n 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 是快一点,也没有很多吧,omnibar也不错。 : 不过ff功能更全面,也更省内存。 : chrome主要太喜欢开进程了,tab少的时候进程也不关,我经常4,5个tab,有10几个 : chrome进程在运行。。。 : 还有就是我上次说的redraw的问题,现在最新版好像好了很多,不过偶尔还是会出现。 : 但是现在新版多了个讨厌的问题。。就是右下角的chrome图标,我打开一个新tab,准 : 备输地址,这个时候都要用余光看看右下角的输入法是不是开着,如果开着要关掉。 : chrome的那个图标让我老以为输入法开着。。。你难道没遇到这个问题么。。
|
b*****l 发帖数: 9499 | 10 空白页倒是真有个 chrome 图标。。。
【在 x******n 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 空白页的右下角,没有?你什么版本?
|
|
|
x******n 发帖数: 9057 | 11 我只有虚拟机虚拟的Mac OS,做不得数,哈哈。
而且SquirrelFish的数组排序性能的数据不是来自Safari,而是来自Adobe Air(也是
用SquirrelFish),Safari的数组排序性能要差好多(但是远没有Chrome那么差),因
为Safari和Chrome都是用WebKit,所以自带的Javascript Shell是一样的,只是用的引
擎不同,所以大概Chrome那么差的性能一部分是来自于那个Shell。
【在 r****y 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 应该测试一下mac下的safari
|
x******n 发帖数: 9057 | 12 没试试Opera?在内存消耗上跟这些不是一个等级的。
【在 r****y 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 我以前嫌ff太费内存的时候做过比较,最后还是回到ff继续用。
|
r****y 发帖数: 26819 | 13 你计算分配的内存精确到byte了?
【在 x******n 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 10M元素的整数数组,SpiderMonkey(firefox的javascript引擎)消耗存储40MB,一点 : 浪费没有(很强啊,它怎么存储这个额外的null值呢。。),SquirrelFish(Safari)消 : 耗48MB,也不错,V8(Chrome)消耗100MB。 : 然后把这10M元素反向排序(就是赋值是0-9999999,然后由大到小排序), : SpiderMonkey额外消耗内存80MB,耗时16秒;SquirrelFish额外消耗120MB,耗时19秒 : ;V8排序1M元素(注意,是1M)的类似数组消耗内存过G,耗时不知道多长,我等不及 : 把进程kill了(这倒也不一定是V8自己就这么差,可能是Chrome提供的Shell有问题, : 虽然按理说不应该会有这么大的overhead)。 : 作为对照,Python存储10M元素的整数数组消耗内存160M,排序几乎是瞬间完成。 : 然后我对比测试了下SpiderMonkey(SM)和SquirrelFish(SF):
|
r****y 发帖数: 26819 | 14 opera好像也试过了,忘了因为什么原因淘汰了。
ff很多功能都很实用,比如读存mht。
【在 x******n 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 没试试Opera?在内存消耗上跟这些不是一个等级的。
|
x******n 发帖数: 9057 | 15 当然是通过创建很多个,然后除一下来实现的。
因为我要基于SpiderMonkey(FF addon)和SquirrelFish(Adobe Air)来写一个潜在
需要高效处理大量数据的桌面应用程序,所以试验了一下。
现在我知道应该大量使用整数数组,少使用字符串,不使用数组的数组。
【在 r****y 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 你计算分配的内存精确到byte了?
|
r****y 发帖数: 26819 | 16 我的意思是你精确地发现了没有分配null结尾?
【在 x******n 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 当然是通过创建很多个,然后除一下来实现的。 : 因为我要基于SpiderMonkey(FF addon)和SquirrelFish(Adobe Air)来写一个潜在 : 需要高效处理大量数据的桌面应用程序,所以试验了一下。 : 现在我知道应该大量使用整数数组,少使用字符串,不使用数组的数组。
|
x******n 发帖数: 9057 | 17 不是,我的意思是说,javascript的整数可以是任何数,可以是0,也可以是null,0和
null是不同的,但是这个null要用什么编码来保存呢?又比如如果其中一个元素根本不
是整数,而是个字符串,或者是个object,这要用什么编码来表示呢?如果一个整数有
比如4个字节的overhead,那没问题,可是它的整数存储太高效了,每个就是4字节,那
么这些metadata存在哪里呢?
【在 r****y 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 我的意思是你精确地发现了没有分配null结尾?
|
r****y 发帖数: 26819 | 18 array是继承object.prototype的,所以是个特殊的object。我觉得你实际查的不是全
部,只是这个object一部分数据。比如它有keys,有length。
【在 x******n 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 不是,我的意思是说,javascript的整数可以是任何数,可以是0,也可以是null,0和 : null是不同的,但是这个null要用什么编码来保存呢?又比如如果其中一个元素根本不 : 是整数,而是个字符串,或者是个object,这要用什么编码来表示呢?如果一个整数有 : 比如4个字节的overhead,那没问题,可是它的整数存储太高效了,每个就是4字节,那 : 么这些metadata存在哪里呢?
|
x******n 发帖数: 9057 | 19 javascript根本不能查object的size,我是通过task manager看的,10M个元素push进
去,内存占用增加40MB,一点假的也没有。它额外存一些length啥的通过这个自然看不
出来,但是如果有per element的metadata,哪怕只是一个bit,内存占用也应该增加1M
多。
我猜大概是采用了类似压缩的算法,因为整形数组最常用,所以没有metadata就是整形
数组,如果是别的再增加metadata.
【在 r****y 的大作中提到】![](/moin_static193/solenoid/img/up.png) : array是继承object.prototype的,所以是个特殊的object。我觉得你实际查的不是全 : 部,只是这个object一部分数据。比如它有keys,有length。
|