xmlgraphics-fop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Austin <jwaus...@sympatico.ca>
Subject Re: String.intern() test and measurement
Date Tue, 02 Dec 2003 17:59:06 GMT
On Tue, 2003-12-02 at 14:04, J.Pietschmann wrote:
> Finn Bock wrote:
> >>                 new DefaultMutableTreeNode(("Attribute (name = '" +
> >>                                            atts.getLocalName(i) + 
> >>                                            "', value = '" +
> >>                                            atts.getValue(i) +
> >> "')").intern() );
> 
> > Here you are also interning the attribute values, right?
> 
> Eh, no. The String "Attribute (name = ';name:', value = ';value:')"
  ^ Canadian ?
> is interned.

But I feel it's similar for the purpose of modelling the behavior in the
SAXTreeValidator.java example. The references held by the parser go away
in this model program. I ensure the strings are unique. That's where the
80M savings comes in. In FOP, many strings are created in the parser and
references to them are stored in the parsed tree. Interning these will
produce memory savings. 

> > But, as Glenn noticed, the attribute names can also be implemented with 
> > enumeration 
> 
> There are no enumerations in pre 1.5 Java. What was meant was that
> strings denoting XSLFO property enumeration tokens can be interned
> as the set is of limited and more or less fixed size, while it is
> probably not prudent to intern the complete XML attribute value
> strings.
> For example:
>    text-decoration="underline overline"
> (Yes, that's valid, provided "overline" is valid).
> The possibly interned strings are "text-decoration" (property name),
> "underline" and "overline" (enumeration tokens).
> Somewhere else, the user might have put
>    text-decoration="overline underline"
> Granted, given that FO source ought to be XSLT or otherwise generated,
> this isn't very likely, but still.

This is why I wrote a perl program to count from a real-world case
(defguide). I haven't concerned myself with how an interned "overline
underline" string is used, just ensured it is stored that way once.

The attribute name space is defined in the XSL-FO spec. So the number
of names is strictly limited. Peter lists 380 or so in PropNames.java.
 
> Another issue is how the values are stored. For example, there are only
> 8 distinct TextDecoration objects. In 0.20.5, basically every Text node
> gets its own instance.
> The weird thing is, when I hacked the PropertyManager to look up the
> actual text decoration in an array of preinstantiated objects, FOP
> run slower and took more memory. Apparently something went wrong. If
> anybody is up there to get it right, please do.

I tried testing 0.20.5 doing things that worked in SAXTReeValidator
and haven't had instant success. The benefits would disappear if the
references passed out of the parser are still held elsewhere in FOP.
Give it some time.

> Same for some other objects, BorderAndPadding and especially FontInfo
> come to mind, although there is more variation.

-- 
John Austin <jwaustin@sympatico.ca>

Mime
View raw message