xmlgraphics-fop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From thomas.dewe...@kodak.com
Subject Re: FOP Memory issues (fwd from fop-users)
Date Fri, 12 Jan 2007 12:00:49 GMT
Hi all,

Andreas L Delmelle <a_l.delmelle@pandora.be> wrote on 01/11/2007 05:24:36 
PM:

> On Jan 11, 2007, at 22:31, J.Pietschmann wrote:
> 
> > Quite some time ago I did some statistics on number of children
> > of FOs, using the FOP examples and FO files from bug reports.
> > The breakdown was roughly the following
> >  ~50% no children, mostly FOText nodes and FOs like region-body
> >     and page-number-citation
> >  ~40% one child, mostly blocks and inlines (fo:wrapper) having
> >     exactly one FOText node as child
> >  <10% 2..10 children

   Just a quick comment on this, given the above stats you might
consider having a single Object field and switch the type of object
from the actual child (when there is a single child) to a List of
children when there are multiple children:

   Object child;

   Child getChild(int idx) {
        if (child instanceof List) return (Child)((List)child).get(idx);
      if (idx != 0) throw new IndexOutOfBoundsException(...);
      return (Child)child;
   }

   int getNumChildren() {
        if (child instanceof List) return ((List)child).size();
      return 1;
   }

   I do this in Batik for the ID HashTable which has similar stats
(you might say that the hashtable can only hold one entry but when
dealing with things like DocumentFragments and detached DOM tree's
it get's a little fuzzy what the ID rules really are).

   Admittedly the code is a little ugly, but you can hide
it from all but the implementing class.
Just something to think about it might give you a significant 
savings (might even be a tad faster...).
Mime
View raw message