| |||||||||||||
McGrath: Proposal for a new Fedora projectMcGrath: Proposal for a new Fedora projectPosted Oct 9, 2010 21:33 UTC (Sat) by oak (subscriber, #2786)In reply to: McGrath: Proposal for a new Fedora project by nix Parent article: McGrath: Proposal for a new Fedora project
This particular comment "thread" is about memory overhead of interpreted languages using both GC and JIT (which is needed for interpreted languages, particularly JavaScript here, to have decent speed). And the overhead of all these together.
If your example was of native code using GC and not having JIT, 1-2MB overhead sounds on the largish side for that sized program, but it of course depends completely on how dynamic your program's memory usage is.
Whether the program does lots and very differently sized allocs and how good its allocation patterns are. Heap works like stack so one should in general alloc last things you're going to free first if you want to minimize fragmentation. The allocator you use may utilize buckets for smaller alloc sizes which can affect this or not.
GC and interpreted languages of course have other advantages, but the topic was memory overhead. :-)
(Log in to post comments)
McGrath: Proposal for a new Fedora project Posted Oct 10, 2010 0:57 UTC (Sun) by nix (subscriber, #2304) [Link]
The code was not native code: it was Lua code embedded in a C string and then executed. So, no, not JITted, byt not native GC either.
1-2Mb overhead, well, yes, it seems excessive because it was tuned to find a good tradeoff between GC frequency/intensity and CPU consumption. (I suspect that most of that overhead is actually heap fragmentation, which even a non-GCed program is exposed to.)
(We are in luck sizewise, though: most of the allocations are the same size. Not all, but most.)
|
|||||||||||||