http://bugzilla.spamassassin.org/show_bug.cgi?id=3776
------- Additional Comments From [EMAIL PROTECTED] 2004-10-13 15:37 ------- yep, the memory is generally freed once processing finishes -- freed to the perl allocator. However, that generally does not get returned to the OS; it remains mapped in the process for future allocations. So it's better to avoid allocating too much if possible. Each hash entry is about 15 bytes for the key, plus string length+1, 15 bytes for the int value, and the entry overhead itself is about 15 bytes too iirc. So with a perfect allocator, that's about 12.5 megs. then there's overhead from allocating a lot of small structures; perl doesn't make them all contiguous, for speed. (perl is generally optimised for speed over memory.) the "75MB" figure is probably including the overhead from the rest of SpamAssassin, which is about 25-30MB iirc in current 3.0.0. so in other words there's no leaking -- it's just an inefficient allocation strategy for this situation, which then never gets freed. it may get reused, but in the meantime, it's not efficient to carry around that many pages, perl may allocate new stuff all over that arena, and it looks bad in ps listings ;) ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
