On Dec 7, 2006, at 22:38, J.Pietschmann wrote:
[EMAIL PROTECTED] wrote:
Interesting. This reminds me that quite some time ago I
tried to get the text decoration property flyweighted
(still in the maintenance code), there are only 8 possible
values. Unfortunately, it failed to pay off, apparently
there is no advantage in using a pointer compared to three
I can imagine that this would probably not save much in the case of
booleans or other primitive types.
A reference is, what, 4 or 8 Bytes (depending on whether the machine
uses 32- or 64-bit addresses)? No matter if equal instances are
generated or not, the reference has to be created anyway: either to a
separate instance, or to the flyweight.
One might notice a marginal difference in case of really massive
The only thing it does save on is the pass through the related class'
constructor. IIRC, a map lookup + fetch + assignment is still
generally faster than having the JVM allocate space in the heap for a
I'm sure using the flyweight pattern on font properties could
reduce the memory footprint, the property bundle is large enough,
and documents rarely use more than two dozen or so of
combinations (e.g. two fonts, one a single variant (normal) and
size, the other three variants (normal, bold, italic), the normal
variant in 4 sizes, for a total of 7 different font property
bundles). BorderAndPadding might be another case, for example by
using a static immutable instance for the "empty" case.
Yep, even for something as simple as 'border=".5pt solid black"',
which could recur on a lot of different FOs.
Currently, there is one tiny save on resources in
if the borders were specified as "none" or not specified at all, the
CBPAB instance will have no references to BorderInfo instances (will
be null for all sides)
It could also improve the situation for properties that are currently
unused (such as CommonAural) and ToBeImplementedProperty. They all
revert to their default/initial values, so this will generate a lot
of equivalent, yet separate Property instances...