in reply to Memory Managment with Subroutines and Objects
It is not strictly true that “cutting loose all references to an object will cause it to be freed.” When the reference count becomes zero, the memory becomes reclaimable, but it might be some time before the memory is reclaimed. (And, even when this does occur, the “amount of memory consumed by this process,” as seen by the operating system, might not go down.)
Usually, it makes the most sense to simply arrange the source code files in some sensible way, such that when Perl has to open one up and parse it, it only has to do so one time and, having done so, it “gets good bang for its buck.” The time will be lost in opening the file and waiting a few milliseconds for the I/O transfer to take place, not in the handling of memory once this has been done. (It’s all virtual memory, anyway, and the operating-system paging subsystem can take care of itself.) Just define Perl objects and put them in .pm files, which you either (probably...) use or (maybe...) require, and in one swell foop you get a nice, easy-to-handle, easy-to-use “software thingy.”
I’d say, and in the very nicest way possible, that you just might be thinking about this thing too much ... that you might be over-engineering it ... striving to overcome a problem that basically won’t occur. Just “determine what The Perl Way is,” and then, “do it The Perl Way.” Or, “c’mon in, the water’s fine.”
| Replies are listed 'Best First'. | |
|---|---|
|
Re^2: Memory Managment with Subroutines and Objects
by locked_user sundialsvc4 (Abbot) on Dec 30, 2010 at 14:08 UTC |