Re: Size of inside out object
by tobyink (Canon) on Jun 05, 2012 at 15:28 UTC
|
| [reply] |
Re: Size of inside out object
by kcott (Archbishop) on Jun 05, 2012 at 17:32 UTC
|
The documentation for Class::Std contains a lengthy discussion of inside-out objects vs. hash-based objects. Specifically related to your question, it refers to inside-out objects as being:
"... just as fast as--and often more memory-efficient than--ordinary hash-based objects."
| [reply] |
|
|
thanks a ton for the reference!
| [reply] |
Re: Size of inside out object
by temporal (Pilgrim) on Jun 05, 2012 at 16:01 UTC
|
IIRC, you'll actually come out slightly ahead (use less memory) if you end up instantiating more objects than you have attributes.
In a classic object model each object will contain a hash of attributes. For inside-out objects you have a hash per attribute regardless of the number of objects.
Strange things are afoot at the Circle-K.
| [reply] |
|
|
Say I have an object "car" with attributes color and speed.
Classical approach:
Car A = hash A with keys color and speed
Car B = hash B with keys color and speed
Inside out approach:
Car A = one hash for color, another for speed
Car B = one hash for color, another for speed
Which one will use less memory?
| [reply] |
|
|
For your given example, both will require two hashes, each with 2 of the 8 slots used. As near as make no difference, the memory usage will de identical for both.
However, lets say you have 10 instances of a class that has 2 attributes:
- Classical: 10 hashes with 2 of 8 slots used ~ 80 hash slots + 20 scalars + 10 hash headers.
- Inside out: 2 hashes each with 10 of 16 slots used ~ 32 hash slots + 20 scalars + 2 hash headers.
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
| [reply] |
|
|
Re: Size of inside out object
by locked_user sundialsvc4 (Abbot) on Jun 06, 2012 at 12:00 UTC
|
I advise that you let your decision be governed, first by the overall simplicity of the resulting application, and second by avoiding the need to unnecessarily store “default” values. If you know that a car is Red unless otherwise specified, you don’t need to store Red.
I suggest that you use a true Perl object, unless you truly don’t know what the set of attributes might be. Here, in “getter” and “setter” routines, you can easily specify whatever logic you need, and do it but once. Perl’s “blessing” technique is good and efficient.
Obviously, some edge-cases of computer programming do from time to time present us with situations where “microseconds matter profoundly,” and the amount of storage that we must for one reason or another consume in-memory is enormous. But if it isn’t, then let concerns of simplicity, reliability, and maintainability win the fight over concerns of space and speed.
| |
|
|
The petitioner asks: How many grams of unsaturated fats do your fast food product contain? And how does that compare with a similar meals that I can cook from scratch at home?
Subtext: I'd like to know the (possibly mortal) costs of the convenience of your product.
The fast food manufacturer diverts: Our products are wholly natural; contain 100% of your daily requirement of vitamin Z-obscure; and help employ many less well educated people in third-worlds countries.
The idea that your perfect-world criteria and more important than the petitioners explicit, requested information is presumptuous in the least.
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
| [reply] |