On Wed, 2003-11-19 at 15:34, Victor Mote wrote:
> ANNOUNCEMENT: I have just committed a change that 1) allows LayoutStrategy
> to tell whether an FO Tree should be built, 2) has Driver act on this, i.e.
> to build an FO Tree only if LayoutStrategy indicates that this should be
> done. This should theoretically allow Peter's logic to be used as a
> LayoutStrategy within the trunk development line. What I have done is
> probably overly simplistic, but I will allow Peter or anyone wishing to work
> on that strategy tell us what additional things are needed to accommodate.
> To start integrating, create a subclass of LayoutStrategy, override the
> foTreeNeeded() method to return false, then write a format() method that
> does the layout work. LayoutStrategy knows its parent Document, which knows
> its parent Driver, so you should be able to get to all of the parsing
> variables that are needed. Let me know if you need help.
> Since configuration is still messed up, you will need to hard-code a change
> to Driver to get your new LayoutStrategy object created.
> Victor Mote

Geez! I was thinking more along the lines of plugging in a few new data
structures for property lookup. I am exploring the old implementation 
through the marvel of code grooming in order to understand it.

Don't worry, I have the time to do this right.

I got a tiny  improvement by playing around in some of PropertyList and
PropertyListBuilder. This is just a throw-away effort of course. I did 
enough tracing this a.m. to realize that my 'linear behaviour' may
be deeply buried. I have done this often enough that I don't
expect more than marginal improvements from grooming/tweaking 
lines of code. [Gone are the days of PL/I and unaligned bit

Before I found out about Alt-Design, I was thinking about using a 
HashMap with property names as keys and a class implementing 
some stack behaviour. Each new FO would conceptually 'push'
new values on a stack for each property in it's list. A smart 
'pop' would allow the entire set of properties for a FO to
be popped together. Hopefully, this design would allow faster
access to the current properties, without a need to search through
higher 'activation records', 'stack frames', contexts or whatever
you choose to call them.

The observations of performance indicate that there are millions of
accesses through PropertyList.get(String propertyName) which are 
sent one-to-one through PropertyList.get( propertyName, true, true)
and thence on to PropertyList.findProperty( propertyName, true ).

Combine this information with the fact that I didn't notice the 
performance of the corresponding put() operations on the HashMap
underneath PropertyList to conclude that retrieval is much more
intensive than storage in this structure.

So I should optimize retrievals.

My plan is to get to know the internals of FOP that are 'in contact
with' the existing code, then get to know the Alt-Design, then play with
more and more of it until I feel comfortable integrating it.

I don't expect fast-track to committer status, I would hope to work
with one or two current participants and package the changes so that
they 'drop in' to place. (We'll see)


Reply via email to