[Issue 3463] Integrate Precise Heap Scanning Into the GC

[d-bugmail at puremagic.com]

http://d.puremagic.com/issues/show_bug.cgi?id=3463



--- Comment #51 from Leandro Lucarella <llucax at gmail.com> 2010-07-25 18:10:01 PDT ---
(In reply to comment #48)
> Here are the profiling results (using perf[1]):
> Non-precise scanning: http://pastebin.com/zRKyc9mW
> Precise scanning:     http://pastebin.com/jPJZLL8p
> 
> It looks like findPool() might be used much more often than before? For
> example, I noticed the mixin code calls findPool() very early, so maybe it's
> being called in some situations where it's not necessary. Also, with the patch
> sizeOf() needs to call findPool(), but I don't think that should make a lot of
> difference (unless is used by the runtime very often for array manipulation).

OTOH, note that all 3 functions have a *lot* of more samples in the precise
case, they are doing a lot more of work. It doesn't look like the code added
for precise scanning should make *that much* extra work, so that made me think,
what if the overhead for storing the type information was significant enough to
make the program eat more memory and those functions were doing more work
because there is more memory to scan and not because scanning takes longer? And
it looks like that might be the problem:

Precise scanning:
Maximum resident set size, in Kilobytes = 1289984
Elapsed real time, in seconds           = 68.56

Non precise scanning:
Maximum resident set size, in Kilobytes = 950400
Elapsed real time, in seconds           = 49.74

Note this pattern:
memory: 950400/1289984 = 0.7367533
time:   49.74/68.56    = 0.7254959

Scary close :)

Maybe dil uses a lot of small objects, and/or a lot of 16/32/etc objects, that
doubles the memory needed to store them because of the bitmask pointer.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------