Don't ask to ask, just ask | |
PerlMonks |
Re^2: Memory overhead of blessed hashesby LanX (Saint) |
on Feb 10, 2021 at 17:58 UTC ( [id://11128191]=note: print w/replies, xml ) | Need Help?? |
> I know it's not your code, I don't know what they did, and I want to avoid another "told you so" situation.² Just fighting off FUD theories that bless had a memory impact and trying to educate myself. > Is it really necessary to hold 100k+ in memory at once? From my understanding: they are building complicated trees (well multi-trees°) within a short time window. > If so, if the primary attribute of each object were just a path where the serialization of the remainder of the object's guts can be found, you might save space. That's a good idea. Tho in my experience are Perl&OS pretty efficient in swapping unused hashes as long as they are small enough. Of course the performance depends on the frequency you need to access those, but the same applies to your serialization idea. Hmm ... Actually this is a good counter argument to insight-out-objects, because class-variables holding data for all objects can't be swapped. So it's sometimes better to keep rarely used "guts" data inside small hashes at lower nested levels.
Cheers Rolf °) elements can have multiple parents (aggregation semantic) ²) see also "Chuck Norris"-ing code
In Section
Seekers of Perl Wisdom
|
|