But when clean up occurs, every scalar has to have its reference count decremented to 0 before it can be released
Actually, during "global destruction", most reference counts are not decremented. Lots of allocated memory isn't free()d either. Perl makes sure to call any DESTROY()s that need to be called. But most ordinary data structures it tries to just leave them allocated and let the act of the process exit()ing efficiently de-allocate everything in one fell swoop rather than making thousands of calls to free() and decrementing every reference count of every item until they all reach zero.
But your explanation might be quite correct for the case being discussed. It certainly seems to fit.
Perhaps the performance could be improved by ensuring that the large hash is not destroyed until the global destruction phase has begun. Though, given the vague code provided so far, I don't see why the hash wouldn't live that long. The OP should probably get to work investigating or just providing more details (like producing a minimal test case that reproduces the problem).
You can also avoid Perl's clean-up phase entirely via POSIX:
use POSIX '_exit'; _exit();
instead of using exit.
BTW, if that simply solves the problem, I do hope the OP will still provide more information so we can reproduce the problem and properly understand it.
- tye
In reply to Re^2: problems with garbage collection (_exit)
by tye
in thread problems with garbage collection
by Anonymous Monk
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |