Mailing-List: contact fop-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: fop-dev@xml.apache.org
Received-SPF: pass (hermes.apache.org: local policy)
Message-ID: <20041013145223.71134.qmail@web60107.mail.yahoo.com>
Date: Wed, 13 Oct 2004 07:52:23 -0700 (PDT)
From: Glen Mazza <grm7793@yahoo.com>
Subject: Re: Performance improvement in property consumption.
To: fop-dev@xml.apache.org
In-Reply-To: <416D060E.3020000@worldonline.dk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii


--- Finn Bock <bckfnn@worldonline.dk> wrote:

> Hi Team,
> 
> I've put together another largish patch that changes
> the way properties
> and used by the FO objects, the layout managers and
> the FOEventHandler
> subclasses.
> 
>     
>
http://issues.apache.org/bugzilla/show_bug.cgi?id=31699
> 
> The performance increase is 42% while at the same
> time using %27 less
> memory. 

... 

> All fo elements are required to
> extract all the
> properties that they need and to store the values as
> instance fields in
> the fo element.
> 

I love the performance boost you're recording but have
a philosophical issue of an "fo object needing a
property"--it is really an issue of the
*FOEventHandler subclass* that needs the
properties--and some handlers need/implement more
properties than others.  

So if we did this at the FO level, in effect, we'd
have to (1) store an instance variable of every valid
property for each FO, given that we wouldn't know
whether the FOEventHandler's needs it beforehand, and
(2) instead of the programmatic convenience of
getPropString(PR_OFFICIAL_PROPERTY_NAME), we'd have to
remember what each of the properties are named in the
FO's (We can probably standardize these though.)  

Another clarification needed:  when would the property
list's memory get released--at the PageSequence level,
or as soon as the FO is finished?  Because the values
of some FO's properties further downstream depend on
an earlier FO's properties, we may not be able to
release the memory when the earlier FO is finished. 
Or, (to support inheritance) we may need to store
instance variables for what may be a very unlikely
event of a child needing that value.

Also, are there any other options for releasing this
memory that you know of? Is there someway this .bind()
or other releasing of memory can be done within the
FOEventHandler subclasses, or at least within
LayoutManager (forgetting about RTF) instead?  

Not ruling this out--just want to be the devil's
advocate here.

Thanks,
Glen