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 fields.] 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) -- John Austin <[EMAIL PROTECTED]>
