Thank you Vyacheslav, Erik Corry also provided some useful insights over here: http://groups.google.com/group/nodejs-dev/browse_thread/thread/ea23816b70d26fa8
On Nov 22, 12:51 pm, Vyacheslav Egorov <[email protected]> wrote: > Hi Joran, > > Here are some insights: > > 0. do not rely on Activity Monitor. Some memory regions could be > committed but not used. There is --trace-gc flag which outputs heap > usage statistics. > > 1. Flat string of length L would occupy L + 12 bytes. > > 2. When you concatenate strings you get cons string as a result, not a > flat string. Cons string ultimately is a pair of pointers to strings > that were concatenated. It occupies 12 + 2*4 bytes. Try rewritting > > set[id + length] = id + length; > > to > > var s = id + length; s.charCodeAt(0); // forces flattening > set[s] = s; > > and measure memory consumption. > > 3. Dictionary with n properties will occupy ~ > 3*4*2*ClosestPowerOfTwo(n) bytes, where ClosestPowerOfTwo(n) = min { p > | n < 2^p } > > 4. result of Math.random is pure double and will occupy 4 + 8 bytes, > but you have to keep in mind that in JS all properties are strings. V8 > optimizes dictionaries for continuous int32 indexes but Math.random > certainly does not fall into this category. > > Hope that helps. > > -- > Vyacheslav Egorov > > > > On Mon, Nov 22, 2010 at 10:09 AM, Joran Greef <[email protected]> wrote: > > I came across this trying to use a Javascript object to provide O(1) > > indexing for sets and sorted sets. > > > I tried the following in Node.js: > > > var set = {}; > > var testMemoryUsage = function() { > > var length = 1000000; > > var id = 'testing'; > > while (length--) { > > set[id + length] = id + length; > > } > > }; > > > I ran the function and then watched memory usage in Activity Monitor. > > On each of several attempts, the process would start out with 20mb and > > then grow to more than 170mb and never come down again, even after > > several minutes. > > > The same thing happens in Chrome, but it goes up to 122mb. > > > Of course the set variable is never dereferenced, but the data stored > > therein is in the order of 25mb. So one would expect the process to > > sit at (20mb + 25mb = 45mb). Give or take a few mb for V8 > > implementation. But 170mb is surprising. Worse, this appears to scale > > with the size of the dictionary. > > > Anyone have any idea what this could be? > > > -- > > v8-users mailing list > > [email protected] > >http://groups.google.com/group/v8-users -- v8-users mailing list [email protected] http://groups.google.com/group/v8-users
