[erlang-questions] Erlang in the browser

[Fredrik Svahn]

> How do you know that it is 40 bytes/character? - in fact how do you know the
> internal size of any JS object. if I say x = {abc:123, def:"xyz", ...}
> etc. how big is this
> object in memory - there must be some hidden pointers associated with
> x, but without reading
> the code for the JS emulator it would be difficult to say how large it is.

40 bytes is what the Chromium heap profiler claims that the shallow
size of the list is. The retained size for my example string
represented as a 144 character list is 5.63 KB which is more or less
exactly 144 chars * 40 bytes. A little bit of testing shows that in
Chromium the size of an object seems to be 24 bytes + 8 bytes/property
which matches the 40 bytes I saw. However I missed to take into
account that the value of the property needs to be stored as well. If
the value of the property is e.g. a javascript string the property
value and its' memory consumption is also shown in the profiler*, but
in case it is a number the size of the property is not shown. The size
of a number seems to be 16 bytes according to separate measurements.
The retained size of 144 chars represented as a JS array is 1.17 KB.

IIRC from a blog post I read about Firefox memory optimizations, the
figures above should be in the same ball park for FF.

> If memory were a problem you'd need to write the GC and use the beam
> memory model ..

An empty window in Chromium has a heap size of 5.8 Mb. With the emu
loaded it consumes 11.5 Mb which isn't bad considering 66 modules are
loaded and started in the example. If optimizing for memory is
interesting (might be for running on mobiles) I would go with
optimizing the code storage array into a typed array first.
Unfortunately this isn't supported yet on a number of browsers
(including the Android one), which is why I only use them in the
loader. Optimizing the loading time on mobile browsers would also come
higher on my list of possible optimizations.

First make it work at all, then optimize, right? ;-)

BR /Fredrik
* Strings are probably a very bad example since they might be stored
outside the heap in Chromium...