http://www.perlmonks.org?node_id=457894


in reply to Re: Doubt about fly-weight objects.
in thread Doubt about fly-weight objects.

IIRC the point of flyweights is when you have a boatload of instances of a class and having each instance carry around the entire state would take a huge amount of memory.

No, all of the data still exists, it is just all stored in one big heap in the class, rather than piecemeal with each obect instance. Saying that this saves memory usage is kind of like saying that dropping something heavy from your hands will reduce the total mass of the universe. Flyweight objects are so named because they, themselves, consume next-to-no memory, but the total memory used is not reduced; it's just used in a different place (within the same process).

------------ :Wq Not an editor command: Wq

Replies are listed 'Best First'.
Re^3: Doubt about fly-weight objects.
by Fletch (Bishop) on May 17, 2005 at 17:48 UTC

    Erm, (using the GoF example of flyweights for characters) if you compare several thousand individual instances of class Letter { char myLetter; } scattered all over the heap versus having several thousand Letter * pointers to the same set of 128/256/n instances living inside the flyweight class it most certainly will use less memory.

      <whacks self on side of head... rattling ensues>

      I still don't get it. Let me make sure I understand what you are saying (please correct me where/if I got something screwed up): You're saying that you've got, let's say: a million instances of class Letter. The instance data of such a class is basically: a single character.

      Now, if you used non-fly-weight objects, you'd have each instance of the class be a reference to a scalar containing a character. So that's one million times a reference + one million times a character. Or, basically, one million times a platform-dependent, but small, number of bytes.

      Let's compare to fly-weights. With fly-weight-objects, you'd have one million times a reference to nothing (probably)... that is a scalar reference pointing to undef, I'd guess. Plus you'd have a hash mapping one million stringifications of a scalar reference to a character... so that hash contains one million characters, plus one million hash keys. That totals to one million times (a scalar reference + a character + a stringified scalar reference). That's considerably more than if you didn't use fly-weight objects (because a 20-odd character long string is pretty big compared to a scalar reference and a single character).

      If you'd chosen some sort of instance data that were actually larger (as opposed to a single character, which is about as small as you can get), then the difference between one reference and a reference plus a hash-key (stringification of that reference) would actually be inconsequential. Your example, though, actually makes fly-weights take up way more than twice as much space (I think).

      So, that's how I interpretted the situation you were laying out. I assume I just misintrpretted it... but how exactly did I?

      ------------ :Wq Not an editor command: Wq
        Your example, though, actually makes fly-weights take up way more than twice as much space (I think).

        You're right.

        So, that's how I interpretted the situation you were laying out. I assume I just misintrpretted it... but how exactly did I?

        The GoF example was dealing with a WYSIWYG word processor, so "character" was more complicated than a single byte.

        For example: A naive implementation of a bitmapped character in a word processor might (in Perl) look something like this:

        my $char = bless { char => 'e', face => 'Times', size => '12pt', bitmap => '... some binary data ...', row => 12, column => 22, }, 'BitmapCharacter'; ... $char->render # draw a 12pt Times letter 'e' at row 12, column 22

        So if we have a a bit of text that says "errol eats enough eggs everyday" then we have 6 x 'e' BitmapCharacter objects that only differ by their row and column attributes.

        In the GoF language we say that the row and column attributes are extrinsic state - they're dependent on the characters context (as opposed to intrinsic state which is context independent).

        The GoF Flyweight pattern is to rip out the extrinsic state from the object so we'd have something like:

        my $char = bless { char => 'e', face => 'Times', size => '12pt', bitmap => '... some binary data ...', }, 'BitmapCharacter'; ... $char->render( 12, 22 ) # draw a 12pt Times letter 'e' at row 12, colu +mn 22

        So the container now has to pass the extrinsic state and we can use the same object for each occurance of each letter - saving lots of space.