JavaScript类型的内存分配 [英] Memory allocation for JavaScript types
问题描述
我正在尝试优化我正在处理的移动应用程序的地狱，我想知道什么占用最小的内存占用（我意识到这可能因浏览器而异）：
I'm trying to optimize the hell out of a mobile app I'm working on, and I'd like to know what takes up the smallest memory footprint (I realize this may vary across browser):
- 对象指针
- 布尔文字
- 数字文字
- 字符串文字
- object pointers
- boolean literals
- number literals
- string literals
理论上理论上应该占用最少的内存空间？
Which should theoretically take the least amount of memory space?
推荐答案
在V8上：
布尔值，数字，字符串，无效0字面值取常量4 / 8字节的内存用于指针或嵌入指针的立即整数值。但是根本没有堆分配，因为字符串文字将被内化。异常可以是大整数或双精度，其中框指针为4/8字节，框为12-16字节。在优化的代码中，本地双精度数可以在寄存器或堆栈中保持未装箱，或者总是只包含双精度数组的数组会将它们保存为未装箱的。
Boolean, number, string, null and void 0 literals take constant 4/8 bytes of memory to for the pointer or the immediate integer value embedded in the pointer. But there is no heap allocation for these at all as a string literal will just be internalized. Exception can be big integers or doubles which are boxed with 4/8 bytes for the box pointer and 12-16 bytes for the box. In optimized code local doubles can stay unboxed in registers or stack, or an array that always contains exclusively doubles will store them unboxed.
考虑生成代码的内容：
function weird(d) {
var a = "foo";
var b = "bar";
var c = "quz";
if( d ) {
sideEffects(a, b, c);
}
}
正如你所看到的，指向字符串的指针是硬编码且没有分配。
As you can see, the pointers to the strings are hard-coded and no allocation happens.
对象标识至少需要12/24字节的普通对象，16/32字节的数组和32/72的功能（+如果需要分配上下文对象，则为~30 / 60字节。如果你运行前沿v8并且身份没有转义为无法内联的函数，你只能在没有堆分配的情况下离开。
Object identities at minimum take 12/24 bytes for plain object, 16/32 bytes for array and 32/72 for function (+ ~30/60 bytes if context object needs to be allocated). You can only get away without heap allocation here if you run bleeding edge v8 and the identity doesn't escape into a function that cannot be inlined.
所以例如：
function arr() {
return [1,2,3]
}
值1,2,3的后备数组将由返回的所有数组共享为写时复制数组。函数但仍需要分配每个数组的唯一标识对象。了解生成的代码的复杂程度。因此，即使使用此优化，如果您不需要数组的唯一标识，只需从上部作用域返回一个数组将避免每次调用该函数时为该标识分配：
The backing array for values 1,2,3 will be shared as a copy-on-write array by all arrays returned by the function but still unique identity object for each array needed to be allocated. See how complicated the generated code is. So even with this optimization, if you don't need unique identities for the arrays, just returning an array from upper scope will avoid allocation for the identity everytime the function is called:
var a = [1,2,3];
function arr() {
return a;
}
如果你有js的内存问题而没有做任何看似疯狂的事情，你肯定会动态创建函数。将所有功能提升到不需要重新创建的级别。正如你从上面所看到的，只有函数的身份才非常胖，因为大多数代码都可以通过利用这个获得静态函数。
If you have memory problems with js without doing anything seemingly crazy, you are surely creating functions dynamically. Hoist all functions to a level where they don't need to be recreated. As you can see from above, merely the identity for a function is very fat already considering most code can get away with static functions by taking advantage of this.
因此，如果您想从中获取任何内容，请避免非IIFE关闭，如果您的目标是性能。显示它们不是问题的任何基准都是破坏的基准。
So if you want to take anything from this, avoid non-IIFE closures if your goal is performance. Any benchmark that shows they are not a problem is a broken benchmark.
你可能有直觉认为当你拥有8GB时额外的内存使用会有什么影响。好吧，它在C中没关系。但是在Javascript中，内存不只是坐在那里，它被垃圾收集器跟踪。存在的内存和对象越多，性能就越差。
You might have intuition that what does additional memory usage matter when you have 8GB. Well it wouldn't matter in C. But in Javascript the memory doesn't just sit there, it is being traced by garbage collector. The more memory and objects that sits there, the worse performance.
只需考虑运行类似：
var l = 1024 * 1024 * 2
var a = new Array(l);
for( var i = 0, len = a.length; i < len; ++i ) {
a[i] = function(){};
}
使用 - trace_gc --trace_gc_verbose --print_cumulative_gc_stat 。 只是看看做了多少工作。
与静态函数比较：
var l = 1024 * 1024 * 2
var a = new Array(l);
var fn = function(){};
for( var i = 0, len = a.length; i < len; ++i ) {
a[i] = fn;
}
这篇关于JavaScript类型的内存分配的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
