xmlgraphics-fop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andreas L. Delmelle" <a_l.delme...@pandora.be>
Subject RE: Performance improvement in property consumption.
Date Thu, 14 Oct 2004 18:41:59 GMT
> -----Original Message-----
> From: Finn Bock [mailto:bckfnn@worldonline.dk]

Hi there,

> [Glen]
> > Why is it more efficient (I know it is, given your
> > metrics, but want to know why)--...
<snip />
> In my proposal the specified and the cached properties are still stored
> in the property list but only the relevant properties are retained in
> the fo object.

Yes, and IIJC, at the same time, you're eliminating the need for downstream
property queries having to be performed through the PropertyList, so the
FObj's can communicate directly (--less underlying HashMap fetches...)

So roughly:
a. FObj1 asks FObj2
b. FObj2 probes its property instance variable
c. FObj2 responds to FObj1

instead of
a. FObj1 asks its PropertyList
b. PropertyList asks FObj2's PropertyList
c. FObj2's PropertyList queries its HashMap
d. FObj2's PropertyList responds to PropertyList
e. PropertyList responds to FObj1

> > So if PropertyList can be thought of as a C-like
> > struct holding the values of its FObj's properties,
> > what you're doing appears to be just taking that
> > struct's member variables and moving them to the FObj.
> No, see above.

To clarify this further: PropertyList seems to be more than simple wrapper
around the individual property-bundles. It offers a functionality of its
own, so needs extra space, and because it needs to be alive to be able to
provide, it currently occupies this extra space longer than strictly
necessary. It's not a simple data structure, it's an object in itself,
occupying memory that won't be GC'ed until the parent FObj is released.
What you seem to propose is: limit the functionality of the PropertyList
object to the translation of the captured lists of attributes to the already
instantiated FOBj's 'properties' --in the sense of instance variables--, and
because storing the props in instance vars eliminates the need for
inter-FObj communication through the PropertyList, it speeds up the process
downstream as well... I like it :-)

> > But, obviously, given the performance/memory boost
> > you're noting, PropertyList *can't* be regarded as a
> > C-like struct.  Why?  Could PropertyList be made more
> > efficient instead of this change--make it more like a
> > C-like struct?
> Speed can be improved, but at the cost of additional memory.

Indeed! While your approach would only affect the size of the different FObj
Classes, not the instantiated FObj's themselves. The latter would only grow
because they now have extra instance variables --but the balance is
ultimately kept since their PropertyList had to store these anyway--, plus
certain portions of occupied memory are released earlier. All the different
PropertyLists' HashMaps for starters... Besides that, I kind of like the
idea of the API reflecting the spec in this way.

> The beauty of my proposal is that we can pick the fastest implementation
> of property assignment and property lookup without worrying about the
> memory because the property list is released.

Unless there's a piece of the PropertyList's functionality I'm overlooking
i.e. Are there conceivable situations where the particular functions offered
by the current PropertyList *have* to be available downstream? And where
they can't be replaced by a similar addition of functionality to the FObj
(--which you always have a reference to anyway)?

If the answer to immediately above questions is 'No', I can dig the beauty
of the approach :-)



View raw message