On Dec 7, 2006, at 22:38, J.Pietschmann wrote:

[EMAIL PROTECTED] wrote:
[snip]

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
booleans.

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 documents (?)

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 new object.


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 CommonBorderPaddingAndBackground: 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...


Cheers,

Andreas

Reply via email to