On 2011-02-28, at 22:35 , chevalma@iro.umontreal.ca wrote:
The compilation for fib uses less than 50 MB on v8 (The total heap size before compiling fib is around 45 MB and no gc is triggered during fib compilation). It means that our object representation uses at least 5X more memory than v8, only on parsing.
I don't think the issue is really one of object size. I would guess that our objects are about as big as theirs by default.
I agree.
The real issue is probably that we create alot of temporary objects during parsing. Our standard library code, for example, converts strings to char code arrays before processing them. If the parser uses the String functions alot, it may be creating temporary arrays and strings every time it does so, which at the time, we have no way of reclaiming since we have no GC.
If the internal char array used by Strings is recreated each time a String function is called, then yes, this would could lead to a lot of objects staying in the heap. This conversion happens in (almost?) every function. My original thought when writing the code was that the internal String data would simply be exposed through the IIR.
V8 probably has standard library code that makes less spurious allocations. Our current library code, particularly the string code, does alot of allocations that could probably be avoided. I think just calling String.prototype.charAt will allocate memory for each call, for example.
I don't see why that is the case. True, the string functions can be rather wasteful, but the only memory that needs to be allocated (and that *should* be allocated) by charAt in particular is what is needed for the returned String object. If Strings are unique, then there should only be one such string per character at most, so it shouldn't be the cause for the high memory cost of parsing.
If we look more carefully at what string functions the parser uses, and optimize those, we may be able to get farther in the compilation. If there are about 650 MB of allocations to initialize the standard library while running in V8, though, that's a little steep to run without a GC, but still possible.
I tend to avoid speculative optimizations like what you're proposing, just because they often end up wasting more resources than what is gained. How could we easily gather evidence to point us toward the most profitable optimizations? I'm not suggesting that string optimizations are not at fault (although I'd like to verify that as well), but if they are, we need to determine which ones are the most hurtful in terms of allocated memory.
Bruno