好像在前年有一阵Hash Collision Denial Of Service恐慌。这种性能问题,如果不针对具体解释器、具体算法库考虑的话,单从语言层面,是不会注意到HashMap Get操作会这么容易就变成O(n)的。对于Haskell,我目前除了知道一点foldr、foldl之类的性能上的固有差别,其它的都无力分析了。写C语言嘛还要考虑性能问题,难道不就应该自动脑补成汇编,考虑的不应该是哪里会有Cache Thrashing、哪里编译器做不了指令级并行优化?和语言自身就更无关系啦。
想起了这个项目:https://github.com/codemix/fast.js
Optimized for Chrome v8 engine.Faster user-land reimplementations for several common builtin native JavaScript functions.
里面解释了为什么Native函数反而低效的原因。
sum [1..10]
空间复杂度是多少?gcc -S
看汇编分析啊。传统的编译型语言,对于什么情况下会复制数据,甚至标准库中某些函数的复杂度,语言本身都有定义,如C、C++、Golang。而像JS这样的语言,如果规范中没有要求(通常也不要求)某个操作的复杂度是O(n)还是O(1),那就只能听随解释器了。至于像Haskell这样的非严格求值的语言嘛~等我读过GHC再说吧。
比如说吧,ECMAScript语言没有规定
Array#sort
使用哪种算法排序,Google v8和Webkit JavaScriptCore都进行了权衡,根据Array大小、是否是SparseArray,选择使用不同的排序算法。有人发现v8在排序超大数组时性能不理想 ,这种性能问题当然不是语言自身固有的,甚至也不是v8引擎固有的,因为说不定人家下个版本就优化了啊。以前都有说法,拼接String用Array#join
性能更好,可后来人家优化了,这方法反而效率变低了。以前我以为Array[P]
一定比Object[P]
速度更快,但考虑下Array.prototype[9]="Whatz!"
,嗯,还是打消这种想当然吧。好像在前年有一阵Hash Collision Denial Of Service恐慌。这种性能问题,如果不针对具体解释器、具体算法库考虑的话,单从语言层面,是不会注意到HashMap Get操作会这么容易就变成O(n)的。对于Haskell,我目前除了知道一点
foldr
、foldl
之类的性能上的固有差别,其它的都无力分析了。写C语言嘛还要考虑性能问题,难道不就应该自动脑补成汇编,考虑的不应该是哪里会有Cache Thrashing、哪里编译器做不了指令级并行优化?和语言自身就更无关系啦。想起了这个项目:https://github.com/codemix/fast.js
Optimized for Chrome v8 engine.Faster user-land reimplementations for several common builtin native JavaScript functions.
里面解释了为什么Native函数反而低效的原因。